Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

[Andrea Arcangeli]

On Thu, 6 Aug 1998, Richard Gooch wrote:

>Yup. I'll send it privately, though :-)

Thanks.

Reading the patch I see that _every_ device driver in the kernel need a
_not_ trivial hack to be devfs registered. This is the main part of the lp
hack:

        if (count) {
-               if (register_chrdev(LP_MAJOR, "lp", &lp_fops)) {
+               if (devfs_register_chrdev(LP_MAJOR, "lp", &lp_fops)) {
                        printk("lp: unable to get major %d\n", LP_MAJOR);
                        return -EIO;
                }
+               devfs_handle = devfs_mk_dir (DEVFS_LP_DIR, 0);
+               for (i = 0; i < LP_NO; ++i)
+               {
+#ifndef CONFIG_DEVFS_DISABLE_OLD_NAMES
+                   void *symlink;
+#endif
+                   char name[16], old_name[16];
+
+                   if (!(lp_table[i].flags & LP_EXIST)) 
+                       continue; /* skip this entry: it doesn't exist. */
+                   sprintf (name, DEVFS_LP_DIR "/%d", i);
+                   sprintf (old_name, "lp%d", i);
+                   handle = devfs_register (name, 0, DEVFS_FL_NONE,
+                                            LP_MAJOR, i,
+                                            S_IFCHR | S_IRUGO | S_IWUGO,
0, 0,
+                                            &lp_fops, NULL);
+#ifndef CONFIG_DEVFS_DISABLE_OLD_NAMES
+                   devfs_mk_symlink (NULL, old_name, 0, DEVFS_FL_NONE,
+                                     name, 0, &symlink);
+                   devfs_set_symlink_destination (symlink, handle);
+#endif
+               }
        } else {
                printk(KERN_INFO "lp: driver loaded but no devices
found\n");
        }

Some month ago you claimed that your devfs patch will not need major hacks
of the current code but it would be pretty compatible with the current
code. Renaming register_chrdev() -> devfs_register_chrdev() you really
don' t care about compatibilty. I understand that a bit of hack on the
device driver is needed since you need to know at registration time which
minor numbers will be vaild and so which one to show in the fs. This could
be done more simply adding a new parameter to register_chrdev and friends. 
That new parameter would be a list of integer that are the valid minor
numbers. Then all the sprintf work could be done by a smarter upper layer. 

In the devfs registration there are many #ifdef and devfs_xxregisterxx and
sprintf() and everything is messy compared to the _only_ clean
register_chrdev() so _I_ think you need to do a cleanup/rewrite of the
devfs interface.

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? 

Another very messy and ugly thing of devfs is the need to handle a tarball
at every shutdown and bootup.

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. 

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

Andrea[s] Arcangeli