mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: viro@parcelfarce.linux.theplanet.co.uk
To: Linus Torvalds <torvalds@transmeta.com>
Cc: Andrew Morton <akpm@digeo.com>, linux-kernel@vger.kernel.org
Subject: Re: 2.5.70 add_disk(disk) re-registering disk->queue->elevator.kobj (bug?!)
Date: Wed, 4 Jun 2003 01:56:25 +0100	[thread overview]
Message-ID: <20030604005625.GF6754@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <3EDD3D5F.3010509@aros.net>

On Tue, Jun 03, 2003 at 06:29:19PM -0600, Lou Langholtz wrote:
> Andrew Morton wrote:
> >The ramdisk driver was recently changed to do exactly this.  From what
> >you say it appears that nbd needs the same treatment.

This is utterly ridiculous.  I realize that sysfs is fashionable, but
it should reflect the existing logics, not the other way round.

Guys, there are very valid reasons to have a queue shared by several
disks.  E.g. it can very well act as a serialization mechanism - and
as the matter of fact does in quite a few drivers.

What the fuck is going on?  It's what, the fifth case when we have
somebody export something in sysfs, ignore the lifetime rules for
objects and go "reality doesn't match my theory, too bad for reality"?

Linus, could we *please* put a moratorium on use of sysfs unless the
persons using it had proven that they understand how the objects they
export are used in the tree?  Enough is enough - we already have netdev
drivers to deal with and have to do that *now* thanks to blind sysfs
export.  Now we get random bdev stuff on top of that?  Absofuckinglutely
marvelous.

  reply	other threads:[~2003-06-04  0:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-03 18:33 Lou Langholtz
2003-06-03 19:07 ` Andrew Morton
2003-06-04  0:29   ` Lou Langholtz
2003-06-04  0:56     ` viro [this message]
2003-06-04 16:08       ` Patrick Mochel
2003-06-04  1:00     ` Andrew Morton
2003-06-04  1:06       ` viro
2003-06-04 16:07         ` Lou Langholtz

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=20030604005625.GF6754@parcelfarce.linux.theplanet.co.uk \
    --to=viro@parcelfarce.linux.theplanet.co.uk \
    --cc=akpm@digeo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.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

all inboxes | Powered by JetHome®