Date:	Mon, 14 Mar 2011 21:59:05 +0000
From:	Andy Green <andy@...mcat.com>
To:	Greg KH <greg@...ah.com>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...aro.org
Subject: Re: [RFC PATCH 3/4] PLATFORM: Introduce async platform_data attach
 api

On 03/14/2011 08:54 PM, Somebody in the thread at some point said:

>> The first issue for usbnet is right now, it has no real insight into
>> what the appropriate interface name is because it is out of its view
>> if the USB Ethernet bridge is soldered onboard or not.  You know, it
>> is also not in a generic userspace's view what is soldered on that
>> board either, so I can only read your pushing of that 'solution' as
>> "get this out of my hair".  The one place that can properly know it
>> right now is the board definition file in the kernel, maybe Device
>> Tree too in the future.
>
> It's not up to the driver to "know" this at all.

Right, it's a matter for the board definition file to know about the 
board.  Not sure how many times I wrote that on this thread, but 
evidently not enough.  It can then send specific functional 
configuration information to the subsystems on the board so they can 
adapt automatically to that environment without stinking up everything 
with private quirk information per-board in the drivers.  That is the 
idea of platform_data and it works really successfully.

It's pointless for you to talk about Device Tree when we'll allegedly 
have the capability to deliver functional configuration data to USB 
devices from board support files, but you claim it's forever evil to use 
it, so what's the point of discussing it?  I dunno why you're bothering 
and it's getting less interesting the more distorted your argumentation 
is becoming trying to hold the line against fixing the drivers.

>> To do it what you are calling the "correct" way in userland, you are
>> okay with the driver selecting the wrong interface name, condemning
>> userland to regenerate board-specific knowledge from grepping
>> /proc/cpuinfo, inferring in userland what can easily and justly be
>> known in the board definition file in kernel, and overriding the
>> wrong interface name.  In all that, Caesar's hands are clean
>> alright, but don't tell me this is a good job and the correct
>> solution.
>
> It really is.  How do you know that I don't want to name this device
> something else than you feel you should?  Do you really want to tell me
> to recompile my kernel just to change the name of the network device?

You know by default if it's going to do it, it ought to try to be 
correct if it's possible, it sounds strange how lassaiz-faire you are 
about these drivers doing the wrong thing.  As Alan pointed out that you 
should either do it well or not bother to do it and have all network 
devices called xxxN until your "wonderful" and "simple" userland rename 
is mandated.  Never mind userland will have to hold a board quirk 
database and query the driver to find out which is WLAN or whatever: 
simplicity.

Nobody said about removing network interface naming, what we're talking 
about is making the driver a touch better so it does the right thing 
first time, adaptively to its platform.

Hey, did you see the smsc95xx driver is configuring its mac address from 
an EEPROM if it's connected instead of letting userland do it, holy 
crap.  I bet those guys who get their MAC address automagically are 
super upset the kernel is cheating userland of some simple wonderfulness.

Ha ha no, just kidding.

Thanks to the other guys for giving their opinions frankly -- I am 
particularly appreciate Mark got the idea immediately -- and I hope 
everyone has a nice evening.

-Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists