[lkml]   [1998]   [Aug]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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.


>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

>> 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
Please read the FAQ at

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