All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@steeleye.com>
To: Andries.Brouwer@cwi.nl
Cc: Linux Kernel <linux-kernel@vger.kernel.org>,
	SCSI Mailing List <linux-scsi@vger.kernel.org>,
	pbadari@us.ibm.com
Subject: Re: [patch for playing] Patch to support 4000 disks and maintain backward compatibility
Date: 11 Apr 2003 09:33:27 -0500	[thread overview]
Message-ID: <1050071610.2078.69.camel@mulgrave> (raw)
In-Reply-To: <UTC200304111142.h3BBgDS11628.aeb@smtp.cwi.nl>

On Fri, 2003-04-11 at 06:42, Andries.Brouwer@cwi.nl wrote:
>     Here is my problem..
> 
>     #insmod ips.o
>       < found 10 disks>
>     #insmod qla2300.o
>       < found 10 disks>
>     #rmmod ips.o
>        <removed 10 disks>
>     #insmod ips.o
>       <found 10 disks - but new names>
> 
> OK, I see what you mean. I agree.

Could you elaborate on the reason you want to keep the minor space
compact?  I don't regard the insmod/rmmod problem as valid because if
you do:

rmmod ips.o
rmmod qla2300.o
insmod qla2300.o
insmod ips.o

All bets are off again. For small kernel dev_t it was essential to keep
a compact minor space because otherwise we coulde run out of minors. 
Sparse minors cause no inefficiency in the mid-layer, or in sd.  There
are problems in sg which could be solved by encoding the device type in
the minor.

> [I see that dougg wants to solve such things by properly naming,
> but that is a higher level. Given a large number space an
> easier solution is to give each module its own part of the
> number space.]

Please, no.  Dividing up the minor space like this would be a step
backwards (adding more policy to the kernel).  Someone would also have
to manage this scheme.

James



  reply	other threads:[~2003-04-11 14:21 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-11 11:42 [patch for playing] Patch to support 4000 disks and maintain backward compatibility Andries.Brouwer
2003-04-11 14:33 ` James Bottomley [this message]
2003-04-11 16:21   ` Badari Pulavarty
  -- strict thread matches above, loose matches on Subject: below --
2003-04-13 13:59 Paul McKenney
2003-04-12  1:13 Paul McKenney
2003-04-12  1:13 ` Paul McKenney
2003-04-12 14:14 ` James Bottomley
2003-04-11 21:13 Andries.Brouwer
2003-04-11 19:45 Andries.Brouwer
2003-04-11 20:14 ` James Bottomley
2003-04-11 23:21   ` Joel Becker
2003-04-11 18:07 Andries.Brouwer
2003-04-11 19:12 ` James Bottomley
2003-04-11  0:13 Andries.Brouwer
2003-04-10 23:53 Andries.Brouwer
2003-04-11  1:09 ` Badari Pulavarty
2003-04-11 10:09   ` Douglas Gilbert
2003-04-11 16:12     ` Badari Pulavarty
2003-04-10 23:33 Andries.Brouwer
2003-04-10 23:37 ` Badari Pulavarty
2003-04-10 23:09 Andries.Brouwer
2003-04-10 23:16 ` Badari Pulavarty
2003-04-10 22:09 Andries.Brouwer
2003-04-10 22:22 ` Badari Pulavarty
2003-04-10 23:57 ` Roman Zippel
2003-04-10 23:57   ` Roman Zippel
2003-04-10 20:39 Badari Pulavarty
2003-04-10 20:54 ` Randy.Dunlap
2003-04-11  0:08 ` Roman Zippel
2003-04-11  0:08   ` Roman Zippel
2003-04-11  1:25   ` Badari Pulavarty
2003-04-11  1:25     ` Badari Pulavarty
2003-04-11 15:43     ` Joel Becker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1050071610.2078.69.camel@mulgrave \
    --to=james.bottomley@steeleye.com \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.