Currently I have implemented code to store BIOS options in the cmos, and the layout of the options is reported by the LinuxBIOS table.
Going forward there are going to be options that we cannot store in the cmos. Either because of size or because of unreliability of the cmos.
I think I want to setup a small jffs2 filesystem in the rom chip, for maintaining and manipulating those options. The concern I have is that this sucks up a lot of flash blocks (at least two), because of the size of the information.
The one piece of information I do not feel comfortable storing there is the cmos boot count and normal/failsafe settings. Because LinuxBIOS must set those and _reliably_ writing to a flash chip appears to be a non-trivial exercise.
By using jffs2 other people can manipulate the stable store as well. My big question is how should I encode the options that LinuxBIOS utilizes.
This is a piece I have not implemented yet, but that looks increasing useful especially as a store of various bits of persistent data. Especially when things like cryptographic keys get involved.
Eric
On 17 Apr 2003, Eric W. Biederman wrote:
By using jffs2 other people can manipulate the stable store as well. My big question is how should I encode the options that LinuxBIOS utilizes.
I really am liking S-expressions for this type of thing nowadays. Trivial to parse, we have a small fast library for this (see http://sourceforge.net/project/showfiles.php?group_id=521&release_id=111...)
ron
ron minnich rminnich@lanl.gov writes:
On 17 Apr 2003, Eric W. Biederman wrote:
By using jffs2 other people can manipulate the stable store as well. My big question is how should I encode the options that LinuxBIOS utilizes.
I really am liking S-expressions for this type of thing nowadays. Trivial to parse, we have a small fast library for this (see http://sourceforge.net/project/showfiles.php?group_id=521&release_id=111...)
For data format I don't have a real problem with that, but there are circumstances I don't think it is appropriate. For settings that can either be in cmos or in a rom chip I definitely want something simpler, so I can use the same data format both places.
But regardless the basic question is does putting a jffs2 filesystem on the flash start to sound like a good idea? And doing things like hard coding filenames or something into the LinuxBIOS code that looks up information.
I'm just playing with ideas at this point. And the real question is how to put the information on the flash. Not what should be the content of the individual files. So S-expr is hopefully irrelevant to this bit of conversation. I have yet to be convinced a self describing format does not have unfortunate size overheads.
Eric
On 17 Apr 2003, Eric W. Biederman wrote:
But regardless the basic question is does putting a jffs2 filesystem on the flash start to sound like a good idea? And doing things like hard coding filenames or something into the LinuxBIOS code that looks up information.
seems ok at first glance.
I'm just playing with ideas at this point. And the real question is how to put the information on the flash. Not what should be the content of the individual files. So S-expr is hopefully irrelevant to this bit of conversation. I have yet to be convinced a self describing format does not have unfortunate size overheads.
Yes, but: isn't a file system in some sense an attempt to get a self-describing format?
ron
ron minnich rminnich@lanl.gov writes:
On 17 Apr 2003, Eric W. Biederman wrote:
But regardless the basic question is does putting a jffs2 filesystem on the flash start to sound like a good idea? And doing things like hard coding filenames or something into the LinuxBIOS code that looks up information.
seems ok at first glance.
I'm just playing with ideas at this point. And the real question is how to put the information on the flash. Not what should be the content of the individual files. So S-expr is hopefully irrelevant to this bit of conversation. I have yet to be convinced a self describing format does not have unfortunate size overheads.
Yes, but: isn't a file system in some sense an attempt to get a self-describing format?
O.k. Lets try describing this another way: - A filesystem is needed so the data is 1) To handle the strangeness of flash chips. 2) Self describing at least on a course level.
For the CMOS I keep the data described in the LinuxBIOS table, with the actual data being stored out of line.
In some instances a binary only representation is better because the value can be directly used.
So if we are already self describing at the fs level do we need S-exprs?
In any event it is important that someplace you define what all of the kinds of data are and what they mean.
And beyond that I think size and simplicity are important. Not so important that we paint ourselves into a corner. But important enough that we keep a close eye on what we are doing.
Eric
On 17 Apr 2003, Eric W. Biederman wrote:
I'm just playing with ideas at this point. And the real question is how to put the information on the flash. Not what should be the content of the individual files. So S-expr is hopefully irrelevant to this bit of conversation. I have yet to be convinced a self describing format does not have unfortunate size overheads.
Also, one other comment, note the silliness with the _MP_ versions would probably not exist with a self-describing format.
ron
-
ebiederman＠lnxi.com -
ron minnich