David Miller wrote:
> Make the change how I suggested, where mdiobus_alloc() retains it's current
> function signature and semantics. Then you can edit drivers as needed rather
> than from the beginning.
Yes, your approach makes much more sense. I should have thought of it.
--
Timur Tabi
Linux
From: Timur Tabi
Date: Thu, 15 Dec 2011 11:12:01 -0600
> Andy Fleming wrote:
>> Why? Doesn't this just obfuscate things a little, while providing no
>> immediate benefit?
>
> I see code like this frequently:
>
> bus = mdiobus_alloc();
> if (bus == NULL)
> return -ENOM
From: Timur Tabi
Date: Thu, 15 Dec 2011 10:51:35 -0600
> Augment mdiobus_alloc() to take a parameter indicating the number of extra
> bytes to allocate for private data. Almost all callers of mdiobus_alloc()
> separately allocate a private data structure. By allowing mdiobus_alloc()
> to alloca
Andy Fleming wrote:
> Why? Doesn't this just obfuscate things a little, while providing no
> immediate benefit?
I see code like this frequently:
bus = mdiobus_alloc();
if (bus == NULL)
return -ENOMEM;
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
if (
On Dec 15, 2011, at 11:51 AM, Timur Tabi wrote:
> Augment mdiobus_alloc() to take a parameter indicating the number of extra
> bytes to allocate for private data. Almost all callers of mdiobus_alloc()
> separately allocate a private data structure. By allowing mdiobus_alloc()
> to allocate extr
Augment mdiobus_alloc() to take a parameter indicating the number of extra
bytes to allocate for private data. Almost all callers of mdiobus_alloc()
separately allocate a private data structure. By allowing mdiobus_alloc()
to allocate extra memory, the two allocations can be merged into one.
Thi
