[lkml]   [2007]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Out of tree module using LSM
On Wed, 28 Nov 2007, wrote:

> So as there is no question the current code does some ugly things it is
> even more true that we would be even more happy to use an official API.

How about becoming involved in creating that official API ?

"A person will stand on the top of a hill for a very long time with their
mouth open before a roast duck will fly in"

> LSM was that and we were happily using it which we won't be able to do if
> it abruptly goes away. Yes it is not a perfect match but until it is
> modified to be better, or until something appropriate is designed and
> implemented, it would be very nice if it could stay.

So, what you're asking for is for us to maintain infrastructure in the
kernel, for your out of tree code, which we could not have even known
about until it was dumped on sourceforge a couple of days ago ?

And you're expecting us to modify it to be "better", for you, but without
us possibly knowing what you want ?

How is this sustainable? Every time we make a change in the kernel code,
do we have to wait for months while all of the (unknown) out of tree users
discover their code is broken and then complain to Linus ?

Do you really thing we should be supporting developers who make zero
effort to engage with the kernel community, and instead abuse kernel APIs
and ship out of tree code to customers?

You are essentially demanding that we provide you with a stable kernel
API. I suggest you review Greg KH's excellent document on the issue:

Also, your users are likely unaware of the risks associated with these
techniques, such as, that they are not actually running "linux" any more,
and that their kernel is made unsupportable by both the community and
their OS vendors when code like this is being used:

* hidden vfsmnt_lock handling
static inline void talpa_vfsmount_lock(void)
spinlock_t* talpa_vfsmount_lock_addr = (spinlock_t *)TALPA_VFSMOUNT_LOCK_ADDR;


Code quality and correctness issues are definitely relevant, and in fact
are directly linked to the fact that out of tree code receives no
community peer review, and is not able to be considered in the general
kernel design & development process.

Hacks like this effectively void support from the community, which is
another way of saying that the user's kernel becomes proprietary once the
module containing it is loaded.

Actually, it's worse than that, as not only is the kernel no longer "open
source", but also lacks even the level of support provided by proprietary
OS vendors (who provide stable interfaces for such purposes).

If you want to resolve this properly, you'll need to do more than complain
to Linus when the upstream APIs (which you are abusing) change.

You'll need to become productively engaged in designing, developing and
maintaining appropriate APIs, which suit not only your specific needs, but
likely those of others, and submit your code for review and upstream

What I'd suggest, is that you create a public mailing list, get the other
AV projects involved, and then work on a set of requirements so that the
general problem can be understood. Then, propose a solution to the
problem and have it reviewed by core kernel folk (cc it to lkml), so that
it can be evaluated in terms of e.g. VFS correctness, maintainability etc.

That would be at least a useful first step in taking this issue seriously.


- James
James Morris
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-11-29 01:15    [W:0.210 / U:1.252 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site