mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Andy Green (林安廸)" <andy@warmcat.com>
Cc: Florian Fainelli <florian@openwrt.org>,
	linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org,
	s-jan@ti.com, arnd@arndb.de, patches@linaro.org,
	tony@atomide.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, rostedt@goodmis.org
Subject: Re: [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values
Date: Tue, 10 Jul 2012 16:20:26 +0100	[thread overview]
Message-ID: <20120710162026.71534607@pyramind.ukuu.org.uk> (raw)
In-Reply-To: <4FFC2712.9020208@warmcat.com>

> Why should Ubuntu, Fedora etc stink up their OSes with Panda-specific 
> workarounds?  And Panda is not the only device with this issue.

Why should we crap all over the kernel for all these board specific
problems ? Userspace code is at least pageable and generally less
security critical.

So your argument from that point of view is bunk. There are tons and tons
of boards doing tons of horrible hacks. If we mangled the generic code
for all of them the result would be a complete unmanagable pile of turd.

The use of locally administered MAC addressing is policy. The helper
belongs in userspace as it's clearly part of what udev is supposed to be
doing via device notifications, instead of your custom mini kernel-udev
hack which is what you've basically created.

We've said no to lots of people (several a year). We've done so for good
reasons. Most of them had more taste than your hack too (ok except the Pi
which was even more broken)

You need a udev rule, one single tiddly udev rule, and perhaps to expose a
sysfs node somewhere if the required generation data is on the board.
Hardly stinking up the userspace is it.

That would also then fix any races with userspace trying to set the MAC,
it would remove the need for the helper. It will avoid encoding
ultra-crappy assumptions like

"To make use of this safely you also need to make sure that any drivers
that may compete for the bus ordinal you are using (eg, mUSB and ehci in
Panda case) are loaded in a deterministic order."

What are you going to do when speeding up booting by parallelising
more probes breaks this kind of garbage assumption ?

To be honest if Fedora needs to deal with an army of craptastic devices
whose vendors can't get a MAC address on the board then they probably
need a single common change to ifup so that if you ifup an interface that
has no MAC it generates a local one. Thats about 6 lines of userspace
code in the config scripts. It's also probably a good default end user
behaviour.

And if you have a real MAC but it's not loaded into the device you can
just shove it into the platform device.

End of problem.

Alan

  parent reply	other threads:[~2012-07-10 15:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-05  2:44 Andy Green
2012-07-05  2:44 ` [PATCH 4 1/4] OMAP: add cpu id register to MAC address helper Andy Green
2012-07-05  2:44 ` [PATCH 4 2/4] NET ethernet introduce mac_platform helper Andy Green
2012-07-05  3:12   ` Joe Perches
2012-07-05  3:20     ` Andy Green
2012-07-05  3:25       ` Joe Perches
2012-07-06 22:40   ` Ben Hutchings
2012-07-05  2:44 ` [PATCH 4 3/4] OMAP4 PANDA register ethernet and wlan for automatic mac allocation Andy Green
2012-07-05  2:45 ` [PATCH 4 4/4] config test config extending omap2plus with wl12xx etc Andy Green
2012-07-10 12:37 ` [PATCH 4 0/4] Add ability to set defaultless network device MAC addresses to deterministic computed locally administered values Florian Fainelli
2012-07-10 12:58   ` "Andy Green (林安廸)"
2012-07-10 13:08     ` Steven Rostedt
2012-07-10 15:20     ` Alan Cox [this message]
2012-07-27  7:26     ` arm interrupt handling Qipeng Zha

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=20120710162026.71534607@pyramind.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=andy@warmcat.com \
    --cc=arnd@arndb.de \
    --cc=florian@openwrt.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=rostedt@goodmis.org \
    --cc=s-jan@ti.com \
    --cc=tony@atomide.com \
    /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

all inboxes | Powered by JetHome®