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

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