Greg KH <gregkh@suse.de> writes:

quoted text
> On Wed, May 07, 2008 at 11:49:19AM -0700, Eric W. Biederman wrote:
>> Unless there is another path I think placing an additional pointer in
>> kobj_type so we can find it through ktype is the simplest solution.
>> Although using the kset is also sane.
>
> Ick, ick, ick :)

Well yes we are dealing with a pile of seemingly unnecessary layers,
that are attempting to add uniformity where no uniformity existed.
That is an easy recipe for ick.

quoted text
>> The easiest and most trivially correct thing to do would be to simply
>> remove the unnecessary check from kobject_rename.  We perform the
>> check at the upper levels in the network anyway.  And kobject_rename
>> is only used by the network stack.
>
> Wireless uses it also for some things, and it requires that it fail if a
> duplicate is found.

Looks like it, that use is brand new, and at first glance I thought
it was another instance of the device_rename case that kobject uses.
Apparently not.

It looks like getting the wireless devices into the network namespace
is going to be interesting.  Since this phy name is user controllable
and shows up in rtnetlink messages it definitely appears to belong in
the network namespace. 

Virtual/logical devices are such a pain.

....

Given that kobject_rename is growing users we definitely need to
fix it so a noop rename does not return -EINVAL.

i.e. if (temp_kobj && (temp_kobj != kobj)) return -EINVAL.
instead of just if (temp_kobj) return -EINVAL;

quoted text
> I thought that s390 also used it, but I don't see
> that usage in the tree anymore, perhaps they switched to something else.

That is the device_move -> kobject_move case.  Very similar (and nice
if we can figure out how to combine them).

quoted text
> good luck,

Thanks.  It looks like we are just about there.

Hopefully we can get this merged soon so there won't be many more sets
of shifting requirements to chase.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html