svn commit: r321920 - head/sys/sys

[Konstantin Belousov]

On Wed, Aug 02, 2017 at 02:26:46PM +0200, Hans Petter Selasky wrote:
> On 08/02/17 13:43, Konstantin Belousov wrote:
> > On Wed, Aug 02, 2017 at 01:27:50PM +0200, Hans Petter Selasky wrote:
> >> On 08/02/17 13:17, Konstantin Belousov wrote:
> >>> But y must be dev_t.
> >>
> >> Sure, but "struct cdev" 's si_drv0 is only "int" . How can it contain
> >> dev_t ?
> > 
> > Why should it contain dev_t ?
> > Linux KPI abused that field it seems.
> > 
> 
> Hi,
> 
> The LinuxKPI uses si_drv0 to contain the output from mkdev(). Before the 
> mkdev() function would fit into 32-bits. Now it is 64-bits.
> 
> I can fix the LinuxKPI bits this time. We can store this information in 
> si_drv1->xxx instead of using si_drv0 and dev2unit().
si_drv1 is 32bit on 32bit platforms.

> 
> > Lets change the focus of the discussion.
> > You cited the
> > struct linux_cdev *
> > linux_find_cdev(const char *name, unsigned major, unsigned minor)
> > function which finds cdev (or some mockup of the native cdev) by major/minor.
> > Where does these major/minor numbers come from ?
> 
> The major number is in the range 0..255 and decides the type of device.
> The minor number is in the range 0..255 aswell typically and defines a 
> unique number for each LinuxKPI created character device.
> 
> > I mean that if they are contructed as major(struct stat.st_rdev) and
> > minor(struct stat.st_rdev), then even the original code looks wrong
> > without the ino64 addition.  Since devfs reports the internal inode
> > number into st_rdev, which formally is not accessible outside the devfs
> > filesystem.  So should the code for linux_find_cdev() changed to match
> > cdevs against inode number ?
> 
> These numbers do not come from any user-visible files. They are just 
> used internally in the kernel to pass around information.
> 
> > cdp_inode is serially generated so on real machine it is really a small
> > number for any /dev node.  You can watch that by ls -l /dev.
> 
> Sure.
> 
> > 
> 
> While at it, I found that contrib/mknod/pack_dev.c, still has hardcoded 
> references to the old makedev():
> 
> > contrib/mknod/pack_dev.c:#define        makedev_freebsd(x,y)    ((portdev_t)((((x) << 8) & 0x0000ff00) | \
> > contrib/mknod/pack_dev.c:               dev = makedev_freebsd(numbers[0], numbers[1]);
> 
> Same goes for: contrib/libarchive/libarchive/archive_pack_dev.c

I do not see how pack_dev.c can be used for anything non-broken on FreeBSD,
at least in connection with devfs.  For non-devfs filesystems it can
be streamlined, of course.

I will look at this later.

> 
> And if you "grep -r makedev /usr/src" you'll find more.
> 
> --HPS