All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Nazarewicz" <m.nazarewicz@samsung.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: linux-usb@vger.kernel.org, Greg KH <greg@kroah.com>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Mike Frysinger <vapier@gentoo.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/8] USB: gadget: __init and __exit tags removed
Date: Mon, 19 Apr 2010 09:57:47 +0200	[thread overview]
Message-ID: <op.vbegell27p4s8u@pikus> (raw)
In-Reply-To: <n2v8bd0f97a1004161640q640bade7xd4887dde5921b79e@mail.gmail.com>

> On Fri, Apr 16, 2010 at 05:49, Michal Nazarewicz wrote:
>> __init, __initdata and __exit tags have have been removed from
>> various files to make it possible for gadgets that do not use
>> the __init/__exit tags to use those.
>>
>> Files in question are related to:
>> * the core composite framework,
>> * the mass storage function (fixing a section mismatch) and
>> * ethernet driver (ACM, ECM, RNDIS).

Mike Frysinger wrote:
> it would be nice if the expected behavior were documented somewhere so
> we dont have to keep thrashing the section markings on the gadget
> drivers.  first they get marked to save space for setups where it
> makes no sense to keep the functions.  then they get tweaked to
> support a semi-dynamic state.  now they're all removed to support yet
> a different setup.

Are you referring to my previous patch by saying "then they get tweaked
to support a semi-dynamic state"? Those were just a proposal which was never
accepted and suggested to remove those tags all together.

> sounds like the system is insufficiently flexible to meet the
> realistic needs of different groups.

Yes, I agree.  That's why in the first version I proposed the __usb_init,
__usb_exit, etc. tags which could be customized prior to including
composite related files.

I would still go with that solution but it was considered, let me
find the exact phrase, "Ick ick ick." :)

What's more, I don't see any other (that is cleaner) solution which
would allow flexibility so it seems what we can either choose
a non-flexible solution proposed by this patch or an ugly solution
proposed by my previous patch.

So basically, I trusted more experienced kernel developer's opinion
on this one.

-- 
Best regards,                                           _     _
  .o. | Liege of Serenely Enlightened Majesty of       o' \,=./ `o
  ..o | Computer Science,  Michał "mina86" Nazarewicz     (o o)
  ooo +---[mina86@mina86.com]---[mina86@jabber.org]---ooO--(_)--Ooo--

  reply	other threads:[~2010-04-19  7:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-16  9:49 [PATCHv3 0/7] The FunctionFS composite function Michal Nazarewicz
2010-04-16  9:49 ` [PATCH 1/8] wait_event_interruptible_locked() interface Michal Nazarewicz
2010-04-16  9:49   ` [PATCH 2/8] fs/timerfd.c: make use of wait_event_interruptible_locked_irq() Michal Nazarewicz
2010-04-16  9:49     ` Michal Nazarewicz
2010-04-16  9:49     ` [PATCH 3/8] USB: gadget: __init and __exit tags removed Michal Nazarewicz
2010-04-16  9:49       ` [PATCH 4/8] USB: f_fs: the FunctionFS driver Michal Nazarewicz
2010-04-16  9:49         ` [PATCH 5/8] USB: g_ffs: the FunctionFS gadget driver Michal Nazarewicz
2010-04-16  9:49           ` [PATCH 6/8] USB: ffs-test: FunctionFS testing program Michal Nazarewicz
2010-04-16  9:49             ` [PATCH 7/8] USB: testusb: an USB testing application Michal Nazarewicz
2010-04-16  9:49               ` [PATCH 8/8] USB: testusb: testusb compatibility with FunctionFS gadget Michal Nazarewicz
2010-04-16 23:40       ` [PATCH 3/8] USB: gadget: __init and __exit tags removed Mike Frysinger
2010-04-19  7:57         ` Michał Nazarewicz [this message]
2010-04-19  8:02           ` Mike Frysinger
2010-04-19  9:04             ` Michał Nazarewicz
2010-04-16 16:10     ` [PATCH 2/8] fs/timerfd.c: make use of wait_event_interruptible_locked_irq() Davide Libenzi
2010-05-04 17:32 ` [PATCHv3 0/7] The FunctionFS composite function Greg KH
2010-05-04 17:32   ` Greg KH
2010-05-05  8:50   ` Michał Nazarewicz
2010-05-05  8:50     ` Michał Nazarewicz

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=op.vbegell27p4s8u@pikus \
    --to=m.nazarewicz@samsung.com \
    --cc=greg@kroah.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=vapier.adi@gmail.com \
    --cc=vapier@gentoo.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.