> Sweet, we're an axis now! That's much better than the other terms Pat
> and I have been called in the past... And everyone knows what's the
> next size jump up from axis :)
Yes, this is definitely cause for celebration. I've always believed that I
was a straight line around which objects rotated. Thanks for the
reassurance ;)
> So here's how driverfs fits into the big picture in one sentance:
>
> Anything that does not have to do with processes
> will go into driverfs.
This is true, as per discussions in Ottawa in June. This will take a long
time, and is not as clear cut as we make it out to sound. For example,
porting things like meminfo and cpuinfo will likely never happen. Though,
we intend to have equivalent information in driverfs. Things like stats
will also take a long, if not indefinite amount of, time to convert
because of performance concerns.
But, the obvious candidates for transition are things like /proc/bus/*,
/proc/ide, /proc/scsi, and at least the /proc/sys/cpu/ part of /proc/sys/.
We've been working on solidifying the various top-level infrastructural
pieces, like device classes, so that the organization of, and correlation
between objects in, driverfs makes sense to at least developers. As
always, mo' better stuff is coming RSN..
> So in this example, we are exporting a number of boot devices as the
> bios told us, so apply the rule stated above, and determine if it should
> go into /proc or not[1].
This is interesting, and I look forward to delving into the code. ACPI is
doing something very similar. One thing I would like to do is create a
'platform' or 'firmware' top-level directory in driverfs in which all the
various firmware drivers can display the data they ascertain from the
firmware. Stay tuned..
> [1] Yes, it's still a bit difficult to figure how to add files to
> driverfs, if you aren't starting with a "struct device" or "struct
> device_driver", but I have seen some very nice documentation on how to
> do it properly written by Pat involving a wonderful example of beer, and
> I'm sure that once he gets back into internet connectivity range, he'll
> be updating it and adding it to the Documentation directory. That
> should be by the end of the week or so.
Two examples are attached:
pub.c: A subsystem that maintains a list of beers that are dyanamically
registered and unregistered. This example is very similar to what is
already there wrt devices and drivers.
When the module is loaded, a top-level directory is created called 'pub',
and a subdirectory is created in that: 'beer'.
A struct beer describes a beer type. A couple of example beers are defined
and are registered with the pub subsystem (pubsystem?). A directory is
created for each, and a number of attributes are exported on behalf of the
beer by the pubsystem. All are read-only for now. (Wouldn't you love to
change the attributes of a beer? ;)
The things to note are the following:
- struct beer_attribute.
This describes an attribute and includes type-safe callbacks to read and
write the attributes.
- BEER_ATTR() macro
This helps you define an attribute for a beer. It creates a structure
called beer_attr_<name>, where <name> is the name of the attribute, and
initializes it properly.
- struct driverfs_ops
This defines the callbacks that driverfs actually calls. These are
responsible for converting between the generic structures to the
pubsystem-specific structures (see to_beer() and to_beer_attr() macros).
This code is pretty much identical to what already exists. I'm not
claiming its perfect, and not many eyes have really looked at what's going
on. I'm sure I'll hear if I'm doing something completely retarded, and am
looking forward to it.
If anyone is really that bored (and sick), extend the pub to include
objects of struct wine, etc. :)
pat.c: An in-kernel representation of myself.
This example exports attributes concerning my current state. I've been
threatening for some time to write patfs, but I decided to port patfs to
driverfs and eat my own dog food. It's pretty shoddy, and doesn't include
a decent way to update my current attributes. But, it's good for about 3
seconds of entertainment.
There is no registration of objects and no dynamic directory or file
creation. I am singular and may not be replicated.
When the module loads, a top-level directory is created named 'pat'. An
array of files are then created, each one for a particular attribute of my
self on this dreary Oregon Saturday.
For defining attributes, I defined struct simple_attribute, which has no
type-specific callbacks; they pass only the buffer, count, and offset.
Because of this, the driverfs_ops for the patsystem are simple.
[ struct simple_attribute can, and likely will be, defined in a common
header for others to use. There is a lot more work that I've done in this
area and I'm currently trying to figure out what to do with it all..]
Everything else in it is pretty self-explanatory (I hope). The patsystem
is pretty much as simple as it gets for exporting attributes of a
subsystem.
The documentation in Documentation/filesystems/driverfs.txt is up to date.
If anyone has any questions, please ask. Other than that, go wild.
-pat
This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:33 EST