>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.
>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/?
>- 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.
>Perhaps, although see above. Not everything has such a simple
>arrangement of device numbers/names.
Yes, in some cases you could need to handle the naming in the lowlevel
stuff.
>> 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.
>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.
>> 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?
>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).
>> 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 ;-).
Andrea[s] Arcangeli
-
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