Re: [BK PATCH] Driver Core fixes for 2.6.0-test3

From: Greg KH (greg_at_kroah.com)
Date: 08/16/03

  • Next message: Stephane Ouellette: "[PATCH 2.4][TRIVIAL][RESEND] Fix warning in arch/i386/kernel/setup.c" 
    Date:	Fri, 15 Aug 2003 20:28:33 -0700
To: Ingo Oeser <ingo.oeser@informatik.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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Stephane Ouellette: "[PATCH 2.4][TRIVIAL][RESEND] Fix warning in arch/i386/kernel/setup.c"

    Relevant Pages

    • tracking down kernel-panic cause?
      ... USB 2 card and an internal drive. ... aforementioned kernel panic. ... PCI: PCI BIOS revision 2.10 entry at 0xfdb01, ... PCI: Using IRQ router SIS at 00:02.0 ...
      (Debian-User)
    • Hard lockup with kernel 2.6.25 and 2.6.25.1
      ... This incident happened only a few hours after booting the new kernel, ... after that it looks like all pci devices get stuck. ... # Generic Driver Options ... # Supported USB Adapters ...
      (Linux-Kernel)
    • PROBLEM: EHCI Driver hard-locks system when USB devices plugged. (2.4.21 & 2.6.0-test2)
      ... The kernel boot messages were copied by hand from 2.6.0-test2, with USB ... PCI: cache line size of 128 is not supported by device 0000:00:1d.7 ... [root@elbmin3 scripts]# sh ./ver_linux ...
      (Linux-Kernel)
    • 2.6.12-rc3: Bad page state at prep_new_page
      ... I'm inclined to suspect a 2.6 kernel bug. ... Allocating PCI resources starting at 30000000 ... Enabling unmasked SIMD FPU exception support... ... USB Universal Host Controller Interface driver v2.2 ...
      (Linux-Kernel)
    • couple of oopses in 2.6.3-gentoo
      ... recognices my usb hd, and then I saw these ... ... Call Trace: ... ACPI: PCI Root Bridge ... Supermount version 2.0.4 for kernel 2.6 ...
      (Linux-Kernel)