From: Greg KH <greg@kroah.com>
To: Ingo Oeser <ingo.oeser@informatik.tu-chemnitz.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [BK PATCH] Driver Core fixes for 2.6.0-test3
Date: Fri, 15 Aug 2003 20:28:33 -0700 [thread overview]
Message-ID: <20030816032833.GA6680@kroah.com> (raw)
In-Reply-To: <20030815215459.Y639@nightmaster.csn.tu-chemnitz.de>
On Fri, Aug 15, 2003 at 09:54:59PM +0200, Ingo Oeser wrote:
> Hi Greg,
Hi, I've brought this back to lkml as I'm getting tired of private email
threads about this topic. Hope you don't mind.
> On Fri, Aug 15, 2003 at 11:25:00AM -0700, Greg KH wrote:
> > Here's some driver core changes that do the following things:
> > - remove struct device.name field and fix up remaining
> > subsystems
>
> Could you point me to the rationale about this?
>
> I for one considered "everything should have a name" policy very
> useful and extendible.
The main problem is that we don't want to be putting name databases in
the kernel, like PCI, PnP, and USB were starting to do. People were
starting to complain that the PCI and USB names were not the "proper"
name, as we didn't have enough room for the "full" name.
Naming databases belong in userspace. For PCI, PnP, and USB we can
determine the name ourselves from userspace using lspci, lspnp, and
lsusb. Getting rid of the name field prevents us from relying on kernel
code when we shouldn't be.
> Not that I would like to change that back, just like to know why
> this is done, why so late and why after introducing it into all
> drivers in core?
We messed up, and we're now fixing that before people start to rely on
it :)
Now some subsystems still want to export a "name" as there is no other
way to determine the type of the device (no vendor or product ids.) For
them, a name field is just fine to have. For example, I moved the name
field back into the i2c_client and i2c_adapter structures for this very
reason.
Hey, we're saving kernel memory, and this is a problem? :)
Hope this helps explain things.
greg k-h
next prev parent reply other threads:[~2003-08-16 3:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-08-15 18:25 [BK PATCH] Driver Core fixes for 2.6.0-test3 Greg KH
2003-08-15 18:25 ` [PATCH] " Greg KH
2003-08-15 18:25 ` Greg KH
2003-08-15 18:25 ` Greg KH
2003-08-15 18:25 ` Greg KH
2003-08-15 18:25 ` Greg KH
2003-08-15 18:25 ` Greg KH
2003-08-15 18:25 ` Greg KH
[not found] ` <20030815215459.Y639@nightmaster.csn.tu-chemnitz.de>
2003-08-16 3:28 ` Greg KH [this message]
2003-08-16 11:09 ` [BK PATCH] " Ingo Oeser
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=20030816032833.GA6680@kroah.com \
--to=greg@kroah.com \
--cc=ingo.oeser@informatik.tu-chemnitz.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox