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

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.
>