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

Dave,

What about non-clone devices?  (Well, I suppose I should just look at the
code instead of asking, but I haven't dug into 2.17 yet...)  On Linux
Fast-STREAMS I used the inode number (32 bit) in a shadow special filesystem
to represent the device and there can be the full 32-bit range of real
(non-clone) devices.

--brian

On Thu, 07 Oct 2004, Dave Grothe wrote:

> 
>    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
>      >
>      >(<[1]http://www.gcom.com/home/linux/lis/dki.html#majorminordev_t>h
>      ttp://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 [[2]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
>      >
>      ><[3]http://gsyc.escet.urjc.es/mailarchive/linux-streams>[4]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
>      >
>      ><[5]http://www.mail-archive.com/[email protected]/m
>      sg00269.html>[6]http://www.mail-archive.com/[email protected]
>      t.urjc.es/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]
>      [7]http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
> 
> References
> 
>    1. http://www.gcom.com/home/linux/lis/dki.html#majorminordev_t>http://www.gcom.com/home/linux/lis/dki.html#majorminordev_t
>    2. mailto:[email protected]
>    3. http://gsyc.escet.urjc.es/mailarchive/linux-streams
>    4. http://gsyc.escet.urjc.es/mailarchive/linux-streams
>    5. http://www.mail-archive.com/[email protected]/msg00269.html
>    6. http://www.mail-archive.com/[email protected]/msg00269.html
>    7. http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email protected]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦