All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: torvalds@transmeta.com, linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] devfs cleanups for 2.5.29
Date: Tue, 30 Jul 2002 16:18:41 -0700	[thread overview]
Message-ID: <20020730231841.GA17955@kroah.com> (raw)
In-Reply-To: <200207302312.g6UNC7Z10529@vindaloo.ras.ucalgary.ca>

On Tue, Jul 30, 2002 at 05:12:07PM -0600, Richard Gooch wrote:
> Greg KH writes:
> > Hi,
> > 
> > When devfs came alone, it created devfs_[un]register_chrdev and
> > devfs_[un]register_blkdev, which required that all drivers be changed to
> > be compatible with devfs. This change has been bothering a lot of people
> > for quite some time :)
> > 
> > These two small changesets (patches to follow this email) fix that
> > problem by removing these functions, and having the original
> > [un]register_chrdev and [un]register_blkdev ask devfs if the operation
> > should be performed _if_ devfs is currently compiled into the kernel.
> > No functionality is changed, but the kernel code base is reduced, and we
> > are back to a common API.
> 
> Your patch misses the reason why I created those functions: some
> drivers had to always register with the major table. With your
> "fixups", those drivers will break when "devfs=only" is passed in. If
> you first fix the drivers so that they work without an entry in the
> major table, then your patch is safe to apply.

Ah, then this "feature" should be written down somewhere.  Which drivers
does this happen for?  And why penalize _all_ of the kernel drivers for
only the few that need this?

thanks,

greg k-h

  reply	other threads:[~2002-07-30 23:16 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-30 22:54 [BK PATCH] devfs cleanups for 2.5.29 Greg KH
2002-07-30 22:54 ` Greg KH
2002-07-30 22:55   ` Greg KH
2002-07-30 23:12 ` Richard Gooch
2002-07-30 23:18   ` Greg KH [this message]
2002-07-30 23:46     ` Greg KH
2002-07-30 23:35   ` Roman Zippel
2002-07-30 23:41     ` Richard Gooch
2002-07-31  0:31       ` Roman Zippel
2002-07-31  0:32         ` Richard Gooch
2002-07-31  9:32           ` Roman Zippel
2002-08-05 22:12             ` Richard Gooch
2002-08-05 22:48               ` Roman Zippel
2002-08-19  0:48                 ` Richard Gooch
2002-08-19  9:37                   ` Roman Zippel
2002-08-20 17:00                     ` Richard Gooch
2002-08-20 17:29                       ` Roman Zippel
2002-08-21  4:01                         ` Richard Gooch
2002-08-21 11:22                           ` Roman Zippel
2002-07-31 20:30 ` Marcin Dalecki
2002-08-01  9:57   ` Jens Axboe

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=20020730231841.GA17955@kroah.com \
    --to=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    --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 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.