[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080806110851.C2DBC3764CE@pmx1.sophos.com>
Date: Wed, 6 Aug 2008 12:07:57 +0100
From: tvrtko.ursulin@...hos.com
To: Adrian Bunk <bunk@...nel.org>
Cc: Arjan van de Ven <arjan@...radead.org>, Greg KH <greg@...ah.com>,
"Press, Jonathan" <Jonathan.Press@...com>,
linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
malware-list@...ts.printk.net
Subject: Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linuxinterfaceforon access
scanning
Adrian Bunk <bunk@...nel.org> wrote on 06/08/2008 11:50:08:
> On Wed, Aug 06, 2008 at 11:05:43AM +0100, tvrtko.ursulin@...hos.com
wrote:
> > Greg KH wrote on 05/08/2008 21:26:21:
> >
> > > > [JON PRESS] I wouldn't call it lazy, actually. It's more like
> > > > "economical" or "ergonomic" -- or, dare I say it --
"user-friendly."
> > In
> > > > this case, the users are the AV vendors who will have to write to
the
> > > > API that will come out of this spec. We will be more inclined to
> > > > appreciate the SDK (for want of a better term) if it covers all
the
> > > > bases, rather than force us to go elsewhere for some of our
> > > > requirements. When we write SDKs, we try to make sure that our
users
> > > > will find whatever they need.
> > >
> > > But realize that you are adding an overhead on us, the kernel
community,
> > > to make your life easier. We are the ones that are taking our time
to
> > > review and comment on this code. We are the ones who will have to
live
> > > with this code for forever, and maintain it over the lifetime of
linux.
> > > So far, you all have shown no willingness to give anything back to
us at
> > > all.
> >
> > We all? How is that true? I for example wrote some code and am willing
to
> > help maintain it if it gets accepted. And as you describe it, it would
be
> > true for any submission because not all things are usefull for all
people,
> > while everything is baggage for the community. And who is the
community? I
> > thought all who take place in discussions, bug reporting, submitting
code,
> > fixing bugs etc are the community.
>
> As an observer of this thread:
>
> - Some set of requirements suddenly appears out of the void on
> linux-kernel.
Because previously it was said to go away and come back with a clear list
of requirements. And here you make it sound like a negative thing. See
what I am talking about?
> - Noone is able and/or willing to exactly describe the problem(s) they
> are trying to solve.
Hopefully we will get there. Very little time has passed since the
discussion has started, even less considering the time zone difference for
some.
> With this status quo the discussion is going nowhere - Linux kernel
> development does not work this way.
>
> The aim is not to include this code, but to find the best technical
> solution for your problem(s) - no matter whether this will have anything
> in common with the list of requirements and the code posted or not.
I completely agree with that. Here I was just pointing out that what Greg
wrote was untrue and exaggerated so not helping the discussion at all.
Tvrtko
Sophos Plc, The Pentagon, Abingdon Science Park, Abingdon,
OX14 3YP, United Kingdom.
Company Reg No 2096520. VAT Reg No GB 348 3873 20.
--
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