Re: RFC: Evolution of the em driver

On Wed, Oct 31, 2007 at 01:16:39AM -0700, Jeremy Chadwick wrote:
For what it's worth, I agree with Scott. I'd rather see a new and
separate driver (presumably igb(4)) than a "hacked up" em(4) driver
trying to handle tons of IC revisions. A good example of the insanity
the latter causes is nve(4) vs. nfe(4). :-)

<metoo>A separate driver is probably cleaner.</metoo>

I'll just make the comment that if a separate driver is written, there
needs to be a clear way for an end user to identify what driver is
needed/preferred for his chipset. We already have cases like
re(4)/rl(4) and sym(4)/ncr(4) where some chips are supported by two
drivers - though generally only one driver fully supports the chip.
This sort of thing is confusing for end users.

--
Peter

Attachment: pgpwF9unf51b1.pgp
Description: PGP signature

Relevant Pages

  • [PATCH 19-rc1] Fix typos in /Documentation : U-Z
    ... when the underlying device was capable of handling the i/o in one shot. ... using dev->irq by the device driver to request for interrupt service ... The EMU10K2 chips have a DSP part which can be programmed to support ... -(This acticle does not deal with the overall functionality of the ...
    (Linux-Kernel)
  • Re: [PATCH] Broadcom 8603 SAS/SATA driver, rough draft
    ... a response queue (DMA ring). ... Or if in SATA mode, ... This driver pretty much completely lacks exception handling. ... I am also writing a driver for Marvell chips that behave ...
    (Linux-Kernel)
  • Re: Porting OpenBSDs sysctl hw.sensors framework to FreeBSD
    ... Are you arguing that the current proposed framework offers little incremental benefit over simply having the sysctl framework in the first place and having each source of information (i.e., device driver) just export it directly? ... All of these chips are supported by two drivers: ... Also, I have to say that I don't run monitoring tools on several of my boxes because I can never figure out which are the right ones to run, and the ones I try inevitably don't work. ... monitoring tools from the ports tree because there are just too many options to choose from, whereas in reality few of them have desired functionality. ...
    (freebsd-arch)
  • Re: Bug in vr(4) driver
    ... I recently started writing a driver for the Via Rhine family of chips ... I noticed a subtle bug in the FreeBSD vrdriver. ... the VR_STICKHW register is not valid on all Rhine ...
    (freebsd-current)
  • Re: Bug in vr(4) driver
    ... I recently started writing a driver for the Via Rhine family of chips ... I noticed a subtle bug in the FreeBSD vrdriver. ... the VR_STICKHW register is not valid on all Rhine ...
    (freebsd-net)