Messages in this thread |  | | | Date | Thu, 6 Aug 1998 02:59:20 +0200 (CEST) | | From | Andrea Arcangeli <> | | Subject | Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???) |
| |
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.
>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
|  |