public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Detlev Zundel <dzu@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address
Date: Tue, 12 May 2009 16:18:25 +0200	[thread overview]
Message-ID: <m2vdo6jtfy.fsf@ohwell.denx.de> (raw)
In-Reply-To: <200905120826.26108.vapier@gentoo.org> (Mike Frysinger's message of "Tue, 12 May 2009 08:26:24 -0400")

Hi Mike,

> On Tuesday 12 May 2009 04:48:28 Detlev Zundel wrote:
>> >> > > how do set a mac for NFS Rootfs?
>> >> >
>> >> > use initramfs
>> >>
>> >> don't you think it's overkill to use a initramfs just for set a mac
>> >> address??
>> >
>> > no, i think it's perfectly reasonable.  and considering you have no other
>> > option here that'll get merged ...
>>
>> Can you please explain to me, why you think it to be reasonable to
>> demand providing an initramfs in the order of 100s of k to set an
>> attribute of a hardware device which has its own driver?
>>
>> Apart from being constantly repeated, I do not understand this reasoning
>> at all.  My (old-school) belief was that an operating system deals with
>> abstracting the hardware thus userspace does not need to (nor should)
>> know too many hw details.
>>
>> Knowing that there is not a clear distinction line, I still fail to see
>> why a mac address of a network interface should be handled by
>> userspace.  Can someone enlighten me here?
>
> no one said it must be done in userspace, that was just one method for doing 
> it.  read the FAQ for other possibilities.

No you lost me completely.  The question cited above was whether you
find it plausible to use initramfs - and thus userspace - to set a mac
address.  You answered that you find this plausible.  This is what I do
not understand.  

I never ran across this outside of linux arm where people seriously
repeat the statement over and over that a whole initramfs with an
initial userspace and a pivot_root is plausible for nfs root whilst
patches of a few lines float around doing the same in the kernel.

Now proof by repetition is not my preferred form of understanding a
problem, so I was asking for an explanation from someone arguing along
the same lines.

Cheers
  Detlev

-- 
We can forgive a man for making a useful thing as long as he does not
admire it.  The only excuse  for making  a useless  thing is that one
admires it intensely.
                                    --- Oscar Wilde
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de

  reply	other threads:[~2009-05-12 14:18 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-11  6:39 [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address Jean-Christophe PLAGNIOL-VILLARD
2009-05-11  6:39 ` [U-Boot] [PATCH 2/4] macb: add set_hw_enetaddr support Jean-Christophe PLAGNIOL-VILLARD
2009-05-11  6:39   ` [U-Boot] [PATCH 3/4] net/dm9000: move the CONFIG_NET_MULTI api Jean-Christophe PLAGNIOL-VILLARD
2009-05-11  6:39     ` [U-Boot] [PATCH 4/4] at91/macb: remove reset_phy callback Jean-Christophe PLAGNIOL-VILLARD
2009-05-12  0:31       ` Ben Warren
2009-05-11 18:02     ` [U-Boot] [PATCH 3/4] net/dm9000: move the CONFIG_NET_MULTI api Mike Frysinger
2009-05-11 23:58       ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-12  0:37         ` Mike Frysinger
2009-05-12  0:30     ` Ben Warren
2009-05-11  9:13   ` [U-Boot] [PATCH 2/4] macb: add set_hw_enetaddr support Haavard Skinnemoen
2009-05-12  0:29   ` Ben Warren
2009-05-11  7:48 ` [U-Boot] [PATCH 1/4] net: extend the netdev to have a common way to set the hw mac address Mike Frysinger
2009-05-11 12:08   ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-11 13:26     ` Wolfgang Denk
2009-05-11 14:24       ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-11 16:01         ` Wolfgang Denk
2009-05-11 16:30           ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-11 16:24         ` Mike Frysinger
2009-05-11 16:37           ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-11 16:56             ` Mike Frysinger
2009-05-12  0:04               ` Jean-Christophe PLAGNIOL-VILLARD
2009-05-12  0:36                 ` Mike Frysinger
2009-05-12  8:48                   ` Detlev Zundel
2009-05-12 12:26                     ` Mike Frysinger
2009-05-12 14:18                       ` Detlev Zundel [this message]
2009-05-12 16:21                         ` Daniel Stenberg
2009-05-12 22:06                         ` Mike Frysinger
2009-05-13  8:41                           ` Detlev Zundel
2009-05-13 18:07                             ` Mike Frysinger
2009-05-15 14:42                               ` Detlev Zundel
2009-05-12 16:59                     ` Scott Wood
2009-05-13  8:39                       ` Detlev Zundel
2009-05-12 17:02                 ` Scott Wood
2009-05-11 17:49             ` Wolfgang Denk
2009-05-11 17:24           ` Mike Frysinger
2009-05-11 17:54             ` Wolfgang Denk
2009-05-12  0:28 ` Ben Warren

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=m2vdo6jtfy.fsf@ohwell.denx.de \
    --to=dzu@denx.de \
    --cc=u-boot@lists.denx.de \
    /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