Messages in this thread | | | Date | Thu, 6 Aug 1998 09:56:25 +1000 | From | Richard Gooch <> | Subject | Re: 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
| |