[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1250497736.20837.39.camel@wall-e>
Date: Mon, 17 Aug 2009 10:28:56 +0200
From: Stefani Seibold <stefani@...bold.net>
To: Alan Cox <alan@...rguk.ukuu.org.uk>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
Arnd Bergmann <arnd@...db.de>,
Andi Kleen <andi@...stfloor.org>,
Amerigo Wang <xiyou.wangcong@...il.com>,
Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 2/7] kfifo: move out spinlock
Am Montag, den 17.08.2009, 09:15 +0100 schrieb Alan Cox:
> > > All over the kernel unlocked function versions have a leading _ name.
> > > It's the kernel convention.
> >
> > Thats is not true in every case. Have a look at list.h - That was the
> > pattern i have implemented the new kfifo API.
>
> Of course it isn't true in every case. Show me a *single* kernel
> convention that is. It's also not true in no cases. foo_locked isn't used
> much at all.
>
> > The main reason to do this was to design a cleaner interface. Because
> > there are very few users of this API, i thought it is a good time and
> > chance to do this.
> >
> > My first draft version does also not renamed this functions, but there
> > was some concerns about the new functionality without modification the
> > function names.
> >
> > Also the remove of the spinlock made is necessary to rename the
> > functions for preventing miss-use by out-of-kernel-tree drivers.
>
> So if you didn't remove the spinlock you wouldn't have to change the API
> and patch all the drivers.
>
No. The kfifo struct in place does made it also necessary to patch all
this drivers.
And the spinlock is in most cases useless, because the API works fine if
only one reader and one writer is using the fifo. This is the common
case.
> > I think the break is not so hard if you believe. All you have to do is
> > to replace or kfifo_get() into kfifo_out_locked() and kfifo_put() into
> > kfifo_in_locked() if you really need the old behavior.
>
> Which is very long winded. If you want longwinded and without breaking
> stuff you can use
>
> foo_unlocked() or unlocked_foo()
>
> which do occur in the kernel (eg ioctl) when we want people to be
> specifically aware of it although according to grep a little less often
> than foo_locked() [discounting foo_is_locked which is general tests]
>
If you like it is very easy to add a compatibility layer, which restores
the old function names. But for what, only for very few users who
depends on it? This will only waste the name space.
--
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