[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.v0pydjk33l0zgt@mnazarewicz-glaptop>
Date: Wed, 24 Aug 2011 14:59:33 +0200
From: "Michal Nazarewicz" <mina86@...a86.com>
To: "Felipe Balbi" <balbi@...com>
Cc: "Alan Stern" <stern@...land.harvard.edu>,
"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
"Yang Rui Rui" <ruirui.r.yang@...to.com>,
"Dave Young" <hidave.darkstar@...il.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv4 1/4] usb: Provide usb_speed_string() function
On Wed, 24 Aug 2011 10:57:39 +0200, Felipe Balbi <balbi@...com> wrote:
> Hi,
>
> On Mon, Aug 22, 2011 at 11:16:07PM +0200, Michal Nazarewicz wrote:
>> >>>>+obj-$(CONFIG_USB) += common.o
>> >>>>+obj-$(CONFIG_USB_GADGET) += common.o
>>
>> >>>Will this cause problems? For example, what if CONFIG_USB is Y and
>> >>>CONFIG_USB_GADGET is M?
>>
>> >>>Also, it seems a little silly to have an entire kernel module devoted
>> >>>to a single, little function.
>>
>> On Mon, 22 Aug 2011 23:06:43 +0200, Alan Stern
>> <stern@...land.harvard.edu> wrote:
>> >You could do:
>> >
>> > obj-$(CONFIG_USB_SUPPORT) += common.o
>> >
>> >which would build that subroutine into the main kernel whenever either
>> >side of the USB stack is enabled.
>>
>> OK. I'll wait for any more possible comments and post changed version
>> by the end of the week.
>
> if it's only for one single function, wouldn't a static inline in a
> common header do ?
That would defeat the purpose a little. The code would not get duplicated
in many source files but the actual compiled code would end up in several
places.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +-----<email/xmpp: mnazarewicz@...gle.com>-----ooO--(_)--Ooo--
--
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