lkml.org 
[lkml]   [1998]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Andrea Arcangeli writes:
> On Thu, 6 Aug 1998, Richard Gooch wrote:
>
> >Yup. I'll send it privately, though :-)
>
> Thanks.
>
> Reading the patch I see that _every_ device driver in the kernel need a
> _not_ trivial hack to be devfs registered. This is the main part of the lp
> hack:
[...]
> Some month ago you claimed that your devfs patch will not need major hacks
> of the current code but it would be pretty compatible with the current
> code. Renaming register_chrdev() -> devfs_register_chrdev() you really
> don' t care about compatibilty. I understand that a bit of hack on the
> device driver is needed since you need to know at registration time which
> minor numbers will be vaild and so which one to show in the fs. This could
> be done more simply adding a new parameter to register_chrdev and friends.
> That new parameter would be a list of integer that are the valid minor
> numbers. Then all the sprintf work could be done by a smarter upper layer.

If you look back at my earlier patches, you'll notice that I had the
register_chrdev() calls wrapped in #ifndef's. Ingo pointed out that it
added lots of extra #ifndef's to the patch and that it was ugly. He
suggested the change that I made to call devfs_register_chrdev()
instead. I checked with Linus and he agreed that replacing the calls
with a wrapper function was neater. So what you see there is *not* an
indication of intent to throw away compatibility, it is done to make
the code neater.

To some extent, I do support your idea of putting the smarts in
register_chrdev() instead. However, there are some problems with this:

- I'd have to hack *every* driver. The devfs patch only hacks some of
the drivers

- Not all drivers can use a simple #minors scheme. Either the names
aren't of the form "%s%d" or there isn't a contiguous set of minors.

However, that said, there may be merit in a hybrid scheme, where
register_chrdev() has extra parameters added to it, including one
which say "don't register a devfs entry: I'm going to do it myself".
This is something I'd have to think about. I'm not sure how much
things would be cleaned up.

> In the devfs registration there are many #ifdef and devfs_xxregisterxx and
> sprintf() and everything is messy compared to the _only_ clean
> register_chrdev() so _I_ think you need to do a cleanup/rewrite of the
> devfs interface.

Perhaps, although see above. Not everything has such a simple
arrangement of device numbers/names.

> There' s no need of the many config option you added. You don' t
> need to add config option at all. Applying the devfs patch should
> result in a completly different device scheme. Why to not use devfs
> at all (breaking old names and so on) if it would work far better?

No, no, no! Devfs *must* have a compatibility option: people need to
be able to switch between devfs and non-devfs kernels. Also, as we've
seen, some people don't like the new SCSI names.

> Another very messy and ugly thing of devfs is the need to handle a
> tarball at every shutdown and bootup.

As I've said in the FAQ, I could add true persistence if needed
(i.e. devfs writes things to a block device). That is a project for
future consideration. I'm not yet convinced there is a real need for
it.
I'm considering writing a small C programme that does the saving and
restoring of permissions instead of using tar.

> The only useful thing of devfs is the workaround of the device
> drivers kdev_t numer without have to play with userlevel code. The
> only people that you replyed "use devfs to do that" was asking about
> how to handle >16SCSI disk.

This isn't true. Think also about USB. Think about when we have 16 bit
majors and we have a search operation for every open of a device node
(the existing table indexing scheme will have to be thrown out).

> devfs could result nice since it autodetect every device driver in the
> kernel and in hardware but note that nobody other than people that is
> playing with devfs run a ls in /dev/. The last time I had to do something
> /dev/ related (but I probably I have not run a ls /dev/) was on:
>
> andrea@dragon:~$ ls -l /etc/fstab
> -rw-r--r-- 1 root root 797 Feb 3 1998 /etc/fstab

I don't agree here, either. Well before I started thinking about
devfs, I would from time to time need to check something in /dev. I
always found it too cluttered. I even went down the path of deleting
inodes, only to have to put them back later when I started adding new
hardware :-(

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:0.111 / U:0.256 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site