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

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.