OK, now I see.
> Entry's simple, but translating back from 64-bit to 16-bit on exit may take
> some thought. Which syscalls return an inode?
Offhand, stat, fstat and lstat.
> Given that most programs which require such low level access are
> available in source form, it'll be rare that this overhead is
> incurred - most processes which use the affected syscalls will be
> recompiled with glibc.
Once again, you don't have to do any of this at all with devfs.
> > Finally, I don't see how your scheme can work to support more SCSI
> > minors. Unless you have a whole new SCSI driver on one of the "high"
> > majors. Yuk. That gets back to the problem of "blocking" libc 5 access
> > to some of your discs.
>
> Add a second major # for the SCSI system, following one of the more sensible
> schemes suggested. Keep the old major/minor numbers, but deprecate them in
> much the same way as the cua devices.
This does look a bit painful.
> This way, legacy programs can still have access to the devices, and
> the new system is available for anything which wants to use it. Your
> devfs will also help legacy programs to use new devices, if
> necessary.
>
> Bringing in a more sensible SCSI naming/numbering scheme has moved
> up on my list of priorities - I trashed my MBR earlier this evening
> because I tried to use my hard drive as a scanner :)
So why not use devfs? The work is done.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu