public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederman@lnxi.com (Eric W. Biederman)
To: linux-mtd@lists.infradead.org
Subject: Q: MTD and NIC Roms...
Date: 13 Feb 2003 00:38:58 -0700	[thread overview]
Message-ID: <m38ywkbpf1.fsf@lnxi.com> (raw)
In-Reply-To: <3E4B37CD.8090507@pobox.com>

Jeff Garzik <jgarzik@pobox.com> writes:

> Eric W. Biederman wrote:
> > Currently I have a patch to eepro100.c that adds an MTD map driver so
> > the onboard rom can be written.  Making code like etherboot easier to
> > flash etc.
> [...]
> > I am currently looking for ideas on ways to cleanly get this code
> > into the kernel, and I am looking for ideas.  The map driver is
> 
> 
> Well... this functionality has existed for a while, and it doesn't need to be in
> the kernel :)
> 
> Donald Becker's diag suite can do flashing. ftp://www.scyld.com/pub/diag/  He
> provides means to program the flash from userspace.

Not on the eepro100, it does look like one or two other kinds of nic
are supported though.  His libflash.c is quite deficient when it comes
to the number of flash chips supported, the correctness of the
implementation of the cfi command set 2, and the completeness of it's
probe routine.

None of which goes into the races, or the portability problems
that arise from doing this in user space.

The linux mtd layer with it's larger user base, and the fact it sits
in the does not have any of those problems with handling flash chips.
And it steadily gets fewer problems as more kinds of flash chips are
looked at, and the problems in the code are addressed generically.

> And I think that's the best place for it.  We _could_ bloat up the kernel code
> by adding the ability flash -- but how many users is that going to serve, that
> are not already served by existing programs?  So, I disagree with getting this
> stuff into the kernel at all.

Given the lack of existing programs for the eepro100 every user served
is a new one.  Plus with the better support libraries provided by the 
linux mtd layer it is easier to do a quality job in the kernel.

I totally agree that this is not day to day functionality, and so it
should not burden the fast common paths of the kernel.  The code was
enclosed in a config option.  It is worth noting one of the busiest
booths at LinuxWorld was the etherboot booth.  And by other counts
as well there are quite a large number of users network booting.   So
the potential user base is significant.

And as David said it really is not that much code.

Eric

  parent reply	other threads:[~2003-02-13  7:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-13  5:45 Q: MTD and NIC Roms Eric W. Biederman
2003-02-13  6:14 ` Jeff Garzik
2003-02-13  6:29   ` David Woodhouse
2003-02-13  6:47     ` Jeff Garzik
2003-02-13  7:38   ` Eric W. Biederman [this message]
2003-02-14  0:33     ` yxh
2003-02-20  3:05       ` 邹应双
2003-02-13 18:34   ` Jeremy Jackson
2003-02-13  6:27 ` David Woodhouse
2003-02-13  7:41   ` Eric W. Biederman
2003-03-06 20:20 ` Jeremy Jackson
2003-04-08 11:52   ` Eric W. Biederman

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=m38ywkbpf1.fsf@lnxi.com \
    --to=ebiederman@lnxi.com \
    --cc=linux-mtd@lists.infradead.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