RE: Issue with limitation of 256 minors per major in LiS 2.16 on Linu x 2.4

Hello Dave:

	With LiS-2.17 on a 2.4 Linux kernel, what is the implication to
	major and minor Linux numbers with the 12/20 number space of
	LiS?  I recall that the LiS numbering has to map to Linux device
	numbers regardless because it's all implemented in the inode,
	and the inode is limited to a 8/8 number space. Will there be
	major number "overrun" with Lis-2.17 on Linux 2.4 kernels?

	Thank you - Matt Gierlach

On Wed, 6 Oct 2004, Dave Grothe wrote:

> The LiS 12/20 internal device type has its origins in LiS-2.17, so you
> can't use it in 2.16.
>
> So you can use your multi-major trick or upgrade to 2.17.  You can try
> LiS-2.17.U.  Before too long there will be an LiS-2.18.
>
> >   status = lis_mknod (node_name, 0666 | S_IFCHR,
> > makedevice(lis_clone_major(), major_num));
>
> In LiS-2.17 this is where you would use UMKDEV instead of
> makedevice.  UMKDEV does the same thing as makedevice except that the dev_t
> that it produces is in external 8/8 form instead of internal 12/20
> form.  The "U" means "user", as in the dev_t that a user sees in the /dev
> directory.
>
> -- Dave
>
> At 02:47 PM 10/6/2004, Eashwaran, P wrote:
> >Dave,
> >
> >Thanks for your quick response.  I do have one and only one clone node in
> >the dev directory.  Let say, that with this strategy I get major=220
> >(clone_drver) and minor=248 for my /dev node.   Assume that all 256 minors
> >(0 to 255) have already been taken by previous opens and that now I'm
> >going to be opening the node for the 257th time.  This time I will be
> >using 256 as the minor number to pass to makedevice.  If I were to not
> >limit myself to an 8-bit minor and decided to and return the devp as as
> >"*devp = makedevice( getmajor(*devp),  256 );"  then won't I be bumping
> >into another major device's range?  I'm a bit confused there.
> >
> >I went back and checked the LiS documentation and, sure enough, it says
> >exactly what you have said in your reply, that LiS internally uses a 12/20
> >format and using the LiS <sys/stream.h> major/minor manipulation routine
> >will guarantee this view
> >(<http://www.gcom.com/home/linux/lis/dki.html#majorminordev_t>http://www.gcom.com/home/linux/lis/dki.html#majorminordev_t).
> >That means I can have 0xFFFFF (a million) minor devices with one LiS major!
> >
> >Now, I'm using LiS 2.16 on Linux 2.4 kernel.  Are you sure that this 12/20
> >major/minor view applies to LiS 2.16 over Linux 2.4 kernel too?
> >
> >Also, the last paragraph of the section referred to by the above HTTP link
> >talks about creation of device node using lis_mknod during driver
> >initialization time and it talks about using UMKDEV(major,minor) for this
> >purpose.  I did not find the definition of UMKDEV anywhere in /usr/src/LiS
> >of the LiS 2.16.18 distribution that I'm using.   However, my driver does
> >use lis_mknod as shown below to create the device node:
> >
> >   /* major_num was obtained as a return value from lis_register_strdev
> >    * when called with 0 as the first argument */
> >   status = lis_mknod (node_name, 0666 | S_IFCHR,
> > makedevice(lis_clone_major(), major_num));
> >
> >I hope this is the right way to create the device node even though I
> >intend to use this clone node for cloning thousands of devices using the
> >LiS 12/20 major/minor representation.
> >
> >Thanks again for your answers.
> >
> >Regards,
> >Eashwaran.
> >
> >
> >----------
> >From: Dave Grothe [mailto:[email protected]]
> >Sent: Wednesday, October 06, 2004 3:02 PM
> >To: Eashwaran, P; '[email protected]'
> >Subject: Re: [Linux-streams] Issue with limitation of 256 minors per major
> >in LiS 2.16 on Linu x 2.4
> >
> >LiS has the status of a file system in the Linux kernel.  That means that
> >it can define its own interpretation for dev_t structures.  Since LiS-2.17
> >it has maintained an internal dev_t with 12 bits of major and 20 bits of minor.
> >
> >If you are operating clone devices then the external 8/8 restrictiveness
> >is not something that you have to be concerned about.  With clone devices
> >you only need one node in /dev for your clone device, and this can fit
> >into the 8/8 representation of the ext2 file system.  Internally in your
> >driver's open routine you can just compute a 20 bit minor device number
> >and return it.
> >
> >If you need thousands of visible device nodes in /dev then you still need
> >to use the multiple-major trick because the external ext2 file system is
> >still 8/8.
> >
> >-- Dave
> >
> >At 01:25 PM 10/6/2004, Eashwaran, P wrote:
> >
> >I tried to check if this issue has been addressed in previous archives,
> >but clicking on
> ><http://gsyc.escet.urjc.es/mailarchive/linux-streams>http://gsyc.escet.urjc.es/mailarchive/linux-streams
> >gives me a "Forbidden" error page!    So, here it is again!  Please feel
> >free to forward me links of older archives if this issue has been
> >previously discussed in this forum.
> >
> >Linux 2.4 allows only 256 minors per major.  This is a severe restriction
> >for us.  Our driver ports on other OSes allow for 1000+ devices.  With the
> >current major/minor allocation scheme on Linux 2.4 we are now limited to
> >only 256 devices.
> >
> >Our user applications know only to open one device file which has major of
> >the LiS clone_drvr and minor as the actual STREAMS device's major number.
> >
> >In other discussions of this topic, I have seen suggestions where the user
> >application opens different device names.
> >All our applications work with one device file, so we cannot have multiple
> >device files with differing major numbers each supporting 256 devices.
> >
> >Currently, the driver uses dynamic allocation with lis_register_strdev
> >(with 0 arg) to obtain they major number dynamically.  Reading a few links
> >on the web related to this (like
> ><http://www.mail-archive.com/[email protected]/msg00269.html>http://www.mail-archive.com/[email protected]/msg00269.html)
> >I've found that one can call the lis_register_strdev multiple times to get
> >multiple major numbers.
> >
> >I can do that in my driver and have an array of 4 major numbers each
> >capable of 256 minor numbers.  My question is: when I return from
> >device_open routine, if I change the major number of the device to another
> >major number (allocated for the same driver) will it work?
> >
> >Lets say that I've majors 248, 250, 247, 253 in that order in my array of
> >4 allocated major numbers for my driver, because I called
> >lis_register_strdev 4 times.  Also, lets say that I'm able to lookup an
> >internal array of 1024 minor devices and am able to determine which one is
> >free to use.  Having said that, if I modify the *devp parameter in the
> >device_open by changing the major number AND minor number and returning
> >from the routine, will that work?  Note that the major/minor pair is still
> >going to map to one of the major numbers that I've allocated dynamically.
> >
> >Even if the above strategy is alright, do you think it will still work
> >even if my driver uses locks.  Currently I use 2 lis_rw_lock_t and 1
> >lis_spin_lock_t structures to safeguard common data and critical sections.
> >
> >The only disadvantage is that there are a limited number of major numbers
> >available.  Linux 2.6 is supposedly going to address this shortage by
> >increasing the number of minors per major and also increasing the number
> >of majors in the system.
> >
> >Any help is appreciated.
> >
> >Thanks & Regards,
> >Eashwaran.
> >
>