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

At 03:51 PM 10/6/2004, Matthew Gierlach wrote:
>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?

No.  LiS uses the 12/20 format internally so clone devices can allocate 
millions of minors per major.  The visible node in the /dev directory must 
still conform to 8/8, but that is just (clone-major, driver-major) which is 
no problem.

-- Dave

>         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://ww 
> w.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.
> > >
> >
>
>_______________________________________________
>Linux-streams mailing list
>[email protected]
>http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams