Messages in this thread | | | Date | Thu, 6 Aug 1998 11:55:29 +1000 | From | Richard Gooch <> | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
Andrea Arcangeli writes: > On Thu, 6 Aug 1998, Richard Gooch wrote: > > >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 > > I haven' t understood very well (I have not old devfs code here) but I > sure trust Ingo more than me ;-). > > >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. > > There are still too much #ifdef for a production patch I think.
I could reduce that further by not putting code that creates devfs entries in #ifdefs. Unfortunately, that will mean that there is a bit of extra dummy object code in the kernel when CONFIG_DEVFS_FS=n, whereas now there is no extra object code.
> >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 > > Are you going to provide a full replacement for /dev/?
Yes. But it takes time. Hence the stuff about backwards compatibility and so on. What is there now covers all the devices available on the systems of a substantial number of users.
> >- 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. > > OK. > > >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. > > Of course. My idea of extending register_chrdev() was pretty general, but > I don' t think that an hybrid scheme can be a lot clean.
Well, I dunno.
> >> 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. > > So put in only the config option of the compatibility names (to allow > booting from an old userspace btw). If I apply devfs it means that I am > going to use it. If your replacement is really good you have not to care > of the old worse code.
Perhaps in the longer term if the Linux community decides the new names are better. In the meantime I'm careful not to break anything. I think that some people have valid reasons for using devfs but sticking with the old names. It certainly makes switching between devfs and non-devfs kernels easy.
> >I'm considering writing a small C programme that does the saving and > >restoring of permissions instead of using tar. > > I am not worried by tar.
IIRC, you were worried about some aspect of the permission saving. So what exactly are your concerns in this area?
> >> 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 > > People asked you about USB?
Yup. I had some interesting discussions with the guy writing USB drivers: it looks like the problems with addressing with SCSI devices are *much* worse with USB. He thought that devfs was the ideal solution to solving the problems he's been grappling with.
> >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). > > I have not understood very well (I don' t know a lot about USB).
It seems that devices are hot-pluggable and that the order of devices on the cable can change a lot. Using device serial numbers (mapping them into devfs) seems to be a sane way of dealing with the mess.
> >> 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 :-( > > Richard, running MAKEDEV a few times it' s very faster and simpler than > implement devfs ;-).
Well, writing devfs was also a learning experience :-) But, now that devfs is written, the effort of using it is lower than administering things otherwise.
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
| |