All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Kay Sievers <kay.sievers@vrfy.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Symlink /sys/class/block to /sys/block
Date: Fri, 25 Feb 2005 14:39:27 -0800	[thread overview]
Message-ID: <20050225223926.GB28014@kroah.com> (raw)
In-Reply-To: <loom.20050225T020954-395@post.gmane.org>

On Fri, Feb 25, 2005 at 01:35:13AM +0000, Kay Sievers wrote:
> Greg KH <gregkh <at> suse.de> writes:
> 
> > 
> > On Wed, Feb 23, 2005 at 09:43:35AM +0000, Malcolm Rowe wrote:
> > > Greg KH writes: 
> > > 
> > > >>Following the discussion in [1], the attached patch creates 
> > > >>/sys/class/block
> > > >>as a symlink to /sys/block. The patch applies to 2.6.11-rc4-bk7.  
> > > >>
> > > >>Please cc: me on any replies - I'm not subscribed to the mailing list. 
> > > >Hm, your patch is linewrapped, and can't be applied :(
> > > 
> > > Bah, and I did send it to myself first, but I guess my mailer un-flowed it 
> > > for me .  I'll try to find a better mailer. 
> > > 
> > > >But more importantly:
> > > >>static void disk_release(struct kobject * kobj)
> > > >
> > > >Did you try to remove a disk (like a usb device) and see what happens
> > > >here?  Hint, this isn't the proper place to remove the symlink...
> > > 
> > > Er, yeah. Oops. 
> > > 
> > > *Is* there a sensible place to remove the symlink from, though?  Nobody 
> > > seems to call subsystem_unregister(&block_subsys), which is the place I'd 
> > > expect to add a call to, and I can't see anything that's otherwise 
> > > obvious... 
> > 
> > If the subsystem is never unregistered, then don't worry about undoing
> > the symlink.
> 
> This symlink will break a lot of applications out there. If there is not a
> _very_ good reason for it, we should not do that.

People seem to want it for some odd reason, I haven't seen a good reason
yet though, let alone a working patch :)

> The "dev" file unfortunately does not tell you if it's a char or block
> device node and that should be solved by something better than matching a
> magic string somewhere in the middle of a devpath.

Use the subsystem value.  If it's "block", it's a block device,
otherwise it's a char device.  Don't we already do this in udev today?

> The hotplug events will still have the /block/* devpath, so this symlink
> will give us nothing than problems.

It will not give hotplug programs issues, as the block devpath still
remains the same.

thanks,

greg k-h

  reply	other threads:[~2005-02-25 23:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-19 23:29 [PATCH] Symlink /sys/class/block to /sys/block Malcolm Rowe
2005-02-22 19:04 ` Greg KH
     [not found]   ` <courier.421C5047.00003EBA@mail.farside.org.uk>
2005-02-24 23:34     ` Greg KH
2005-02-25  1:35       ` Kay Sievers
2005-02-25 22:39         ` Greg KH [this message]
2005-02-25 23:53           ` Kay Sievers
2005-02-25 23:58             ` Greg KH
2005-02-22 23:06 ` Chris Wedgwood
2005-02-22 23:21   ` Greg KH

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=20050225223926.GB28014@kroah.com \
    --to=greg@kroah.com \
    --cc=kay.sievers@vrfy.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.