linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
To: Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@osdl.org>,
	Laurent Riffard <laurent.riffard@free.fr>,
	linux-kernel@vger.kernel.org, Matt Mackall <mpm@selenic.com>
Subject: Re: 2.6.11-rc3-mm1 : can't insmod dm-mod
Date: Sat, 5 Feb 2005 20:03:10 +0000	[thread overview]
Message-ID: <20050205200310.GN8859@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <20050205162945.GA3928@infradead.org>

On Sat, Feb 05, 2005 at 04:29:45PM +0000, Christoph Hellwig wrote:
> On Sat, Feb 05, 2005 at 03:26:05AM -0800, Andrew Morton wrote:
> > You've enabled CONFIG_BASE_SMALL and so the major_names[] hashtable has
> > just one element.  device-mapper uses dynamic major allocation, the range
> > of which is limited to the size of the top-level major_names[] array.  You
> > ran out of slots and register_blkdev() failed.
> > 
> > So for now I guess we must drop base-small-shrink-major_names-hash.patch.
> > 
> > Al, that code looks rather crappy.  Shouldn't we be using an idr tree or
> > something?
> 
> It'd be nice to see major_names just gone completely.  It's only used
> for /proc/devices output, and with the infrastucture for easily sharing
> majors that one is completely misleading..

ACK.  Moreover, dynamic registration of *majors* makes very little sense
these days - about as much as setting lower limit on IP block registration
to /12.

IMO we should put a large part of device number space for dynamic allocations
(current static ones barely scratch the surface - we could easily leave
upper half and nobody'd noticed) and use e.g. buddy allocator within it.
With allocation requests taking size of area as argument (rounded up to
power of 2, which it normally would be anyway).

Any objections to that?  Hell, we can even have register_blkdev() without
a fixed major calling blkdev_allocate(name, 1<<20) and then eliminate the
callers in favour of saner-sized requests.  Then kill register_blkdev()
completely...

  reply	other threads:[~2005-02-05 20:06 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-04 18:33 2.6.11-rc3-mm1 Andrew Morton
2005-02-04 20:11 ` [patch] 2.6.11-rc3-mm1: fix swsusp with gcc 3.4 Adrian Bunk
2005-02-04 21:51   ` Rafael J. Wysocki
2005-02-05  9:32     ` Pavel Machek
2005-02-04 20:44 ` 2.6.11-rc3-mm1 (compile stats) John Cherry
2005-02-04 21:13   ` Andrew Morton
     [not found]     ` <1107553914.14618.12.camel@cherrypit.pdx.osdl.net>
2005-02-04 23:31       ` John Cherry
2005-02-04 21:08 ` Add changelog entries for bk-trees? Sam Ravnborg
2005-02-04 22:17 ` 2.6.11-rc3-mm1 Sean Neakums
2005-02-04 23:57   ` 2.6.11-rc3-mm1 Benjamin Herrenschmidt
2005-02-05  0:05     ` 2.6.11-rc3-mm1 Sean Neakums
2005-02-05  0:16       ` 2.6.11-rc3-mm1 Benjamin Herrenschmidt
2005-02-05  0:54         ` 2.6.11-rc3-mm1 Bartlomiej Zolnierkiewicz
2005-02-05 10:48           ` 2.6.11-rc3-mm1 Sean Neakums
2005-02-05 22:35             ` 2.6.11-rc3-mm1 Benjamin Herrenschmidt
2005-02-04 23:50 ` 2.6.11-rc3-mm1: device_resume() hangs on Athlon64 Rafael J. Wysocki
2005-02-05  6:35 ` bk-usb is now safe (was 2.6.11-rc3-mm1) Greg KH
2005-02-05  8:47 ` 2.6.11-rc3-mm1 : can't insmod dm-mod Laurent Riffard
2005-02-05 11:26   ` Andrew Morton
2005-02-05 13:25     ` Laurent Riffard
2005-02-05 16:29     ` Christoph Hellwig
2005-02-05 20:03       ` Al Viro [this message]
2005-02-05 12:23 ` 2.6.11-rc3-mm1 William Lee Irwin III
2005-02-05 12:44 ` 2.6.11-rc3-mm1: kobject_register fails for processor on Athlon64 Rafael J. Wysocki
2005-02-05 13:11 ` 2.6.11-rc3-mm1: softlockup and suspend/resume Rafael J. Wysocki
2005-02-05 14:35   ` Ingo Molnar
2005-02-05 14:48     ` Rafael J. Wysocki
2005-02-05 19:07       ` Ingo Molnar
2005-02-06 19:15         ` Rafael J. Wysocki
2005-02-07  8:57           ` Ingo Molnar
2005-02-07 12:53             ` Rafael J. Wysocki
2005-02-08 11:04               ` Ingo Molnar
2005-02-09 16:35                 ` Rafael J. Wysocki
2005-02-10  0:22                   ` 2.6.11-rc3-mm1: softlockup and suspend/resume [update] Rafael J. Wysocki
2005-02-05 19:48       ` 2.6.11-rc3-mm1: softlockup and suspend/resume Pavel Machek
2005-02-05 19:47     ` Pavel Machek
2005-02-05 18:10 ` 2.6.11-rc3-mm1 Rogério Brito
2005-02-05 18:43   ` 2.6.11-rc3-mm1 Jurriaan
2005-02-05 22:28     ` 2.6.11-rc3-mm1 Rogério Brito
2005-02-05 22:45 ` irq 10: nobody cared! (was: Re: 2.6.11-rc3-mm1) Rogério Brito
2005-02-05 22:48   ` Rogério Brito
2005-02-06  2:36   ` William Park
2005-02-06  9:07     ` Rogério Brito
2005-02-12 22:21   ` William Park
2005-02-12 22:47     ` Rogério Brito
2005-02-12 23:21       ` William Park
2005-02-12 23:50         ` Rogério Brito
2005-02-13  1:41           ` William Park
2005-02-13 16:37             ` Rogério Brito
2005-02-13 16:56             ` Rogério Brito
2005-02-13 18:49             ` [Partially solved] " Rogério Brito
2005-02-06 10:07 ` 2.6.11-rc3-mm1 Peter Osterlund
2005-02-06 10:33   ` 2.6.11-rc3-mm1 Benjamin Herrenschmidt
2005-02-06 12:14     ` 2.6.11-rc3-mm1 Peter Osterlund
2005-02-06 21:22       ` 2.6.11-rc3-mm1 Peter Osterlund
2005-02-07 17:22         ` 2.6.11-rc3-mm1 Robert Love
2005-02-08 23:08           ` 2.6.11-rc3-mm1 Peter Osterlund
2005-02-06 12:30     ` 2.6.11-rc3-mm1 Joseph Fannin
2005-02-09  3:58 ` 2.6.11-rc3-mm1 Marcos D. Marado Torres
2005-02-09  4:54   ` 2.6.11-rc3-mm1 Andrew Morton
2005-02-09  8:55     ` 2.6.11-rc3-mm1 Barry K. Nathan
2005-02-09  5:00   ` 2.6.11-rc3-mm1 Zwane Mwaikambo
2005-02-10  4:12   ` 2.6.11-rc3-mm1 Andrew Morton
2005-02-10  4:32     ` 2.6.11-rc3-mm1 Barry K. Nathan
2005-02-09  5:59 ` 2.6.11-rc3-mm1: two oops on startup Clemens Schwaighofer
2005-02-09  6:09   ` Andrew Morton
2005-02-09  6:14     ` Clemens Schwaighofer

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=20050205200310.GN8859@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=akpm@osdl.org \
    --cc=hch@infradead.org \
    --cc=laurent.riffard@free.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpm@selenic.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).