udev_t in the kernel but still called dev_t in userland.
Provide functions to manipulate both types:
major() umajor()
minor() uminor()
makedev() umakedev()
dev2udev() udev2dev()
For now they're functions, they will become in-line functions
after one of the next two steps in this process.
Return major/minor/makedev to macro-hood for userland.
Register a name in cdevsw[] for the "filedescriptor" driver.
In the kernel the udev_t appears in places where we have the
major/minor number combination, (ie: a potential device: we
may not have the driver nor the device), like in inodes, vattr,
cdevsw registration and so on, whereas the dev_t appears where
we carry around a reference to a actual device.
In the future the cdevsw and the aliased-from vnode will be hung
directly from the dev_t, along with up to two softc pointers for
the device driver and a few houskeeping bits. This will essentially
replace the current "alias" check code (same buck, bigger bang).
A little stunt has been provided to try to catch places where the
wrong type is being used (dev_t vs udev_t), if you see something
not working, #undef DEVT_FASCIST in kern/kern_conf.c and see if
it makes a difference. If it does, please try to track it down
(many hands make light work) or at least try to reproduce it
as simply as possible, and describe how to do that.
Without DEVT_FASCIST I belive this patch is a no-op.
Stylistic/posixoid comments about the userland view of the <sys/*.h>
files welcome now, from userland they now contain the end result.
Next planned step: make all dev_t's refer to the same devsw[] which
means convert BLK's to CHR's at the perimeter of the vnodes and
other places where they enter the game (bootdev, mknod, sysctl).
cannot yet be closed, though.
I hope I got all credits right, and that the multiple submitted by lines
do not break anyone's scripts...
PR: kern/5038, kern/5567
Submitted by: Keith Jang <keith@email.gcn.net.tw>
Submitted by: Joachim Kuebart <joki@kuebart.stuttgart.netsurf.de>
Submitted by: Byung Yang <byung@wam.umd.edu>
Submitted by: Motomichi Matsuzaki <mzaki@e-mail.ne.jp>
changes, so don't expect to be able to run the kernel as-is (very well)
without the appropriate Lite/2 userland changes.
The system boots and can mount UFS filesystems.
Untested: ext2fs, msdosfs, NFS
Known problems: Incorrect Berkeley ID strings in some files.
Mount_std mounts will not work until the getfsent
library routine is changed.
Reviewed by: various people
Submitted by: Jeffery Hsu <hsu@freebsd.org>
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
cd9660_rrip.c:
Added lots of bogus casts to hide type errors exposed by the prototypes.
(Different structs are assumed to have a common prefix.)
cd9660_vnops.c:
Finished staticizing.
(original "High Sierra") CD format. I've already implemented this for
1.1.5.1 (and posted to -hackers), but didn't get any response to it.
Perhaps i'm the only one who has such an old CD lying around...
Everything is done empirically, but i had three of them around (from
different vendors), so there's a high probability that i've got it
right. :)
Remove the unnecessary inclusion of disklabel.h in cd9660_vfsops.c so
that I don't have to worry about the latter when changing disklabel.h.
Supply prototypes for some functions that were implicitly declared and
fix the resulting warnings and errors (timevals were punned to timespecs).
device block which was stopping symbolic links working.
cd9660_readdir was incorrectly casting a pointer to the d_namlen field of a
struct dirent to a (u_short*) which caused the directory entries "." and ".."
to read incorrectly.
Submitted by: dfr
