Michael Wood wrote:
> Are you sure? From my brief look at linux/fs/devfs/base.c
> devfs_register_chrdev checks to see if you want only devfs (or
> something like that. devfs=only provided at boot.) and then
> calls register_chrdev if this is not the case. i.e. it does not
> call devfs_register for you. Or was I looking in the wrong
> place?
No, you're right ... I had confused devfs_register_chrdev with
some of the other convenience routines. Even worse, I had in fact
completely neglected the devfs=only mode :-(
This makes everything more complex than I mentioned in my first
mail: with devfs=only you are supposed to completely rely on
the devfs layer providing *both* the name -> major/minor and
major/minor -> device driver mappings. In this mode, you should
*not* register your major number with the regular register_chrdev
or register_blkdev calls.
So, it appears the correct sequence of calls is:
First
devfs_register_chrdev ( ... major, fops ... )
to register the major number with the regular chrdev layer
(unless devfs=only), and then
devfs_register ( ... major, minor, fops ... )
to register the actual device node with devfs ...
*However* there are still various problems: we want dynamic
major number allocation, and rely on register_chrdev returing
the allocated major. If devfs=only, devfs_register_chrdev
would not allocate a major, and this devfs_register would
probably not work correctly. You'd have to specify the
DEVFS_FL_AUTO_DEVNUM flag in that case ...
Furthermore, we want the source code to compile on kernel
versions that do not yet have the devfs routines, so we don't
want to use devfs_register_chrdev unconditionally in any case.
I guess the easiest thing would be to leave everything as is;
this should work even in the devfs=only case (you *can* call
register_chrdev even there).
To simplify everything, we might think of switching to a
'misc' device; if we do that, we not only don't waste a
complete major just for one device, but we also get all the
devfs stuff done for us by the generic 'misc' device layer ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
[EMAIL PROTECTED]
