Re: [GIT PULL] kdbus for 4.1-rc1

[One Thousand Gnomes]

On Wed, 15 Apr 2015 19:31:45 +0200
> Don't make idle comments, the tty layer is far more complex and larger
> than the kdbus code, with much nastier issues and problems.  And we
> handle that just fine :)

The tty layer is the way it is because of design decisions dating back 20
years that were (with hindsight) wrong coupled with the fact that POSIX
took a lot of the behavioural guarantees from an armwaving claim about
what Unix(tm) implemented without thinking about how to implement them
(as far as I can tell - given many of the guarantees are broken in Unix!)

> I'll again refer to ALSA here, no one writes a "raw" ALSA program, they
> all use the library to interact with the kernel.  Do that here, there
> are wonderful dbus libraries out there, for all languages.  Use them
> instead.

Agreed entirely - I don't disagree that we need a fast messaging layer.
The question is what bits belong in kernel. Go wants one, JMS wants one,
porting from stuff like QNX wants one (although they use the POSIX API
on QNX), MPI wants one (but with some useful and subtly different
semantics), various embedded things from tiny uKernels want one.

The question is what the kernel bit should actually look like, and how
many we need.

My guess is that we actually have three of the big use cases covered

- futexes and shared memory cover the tiny uKernel emulation bits (and on
  a lawnmower engine sized ARM thats probably the only way to get the
  speed approaching that of a tiny rtos)
- posix queues cover things like QNX porting
- publish/subscribe - via tmpfs

but we don't cover

- multicasting
- some types of credential and authority passing
- scatter/gather without excessive userspace wakes
 
> > Is there a reason that this patch must go in this merge window?
> 
> What makes this merge window any different from any other?  Again, I
> explained why I asked it to be merged at this point in time.  If people
> have technical issues with it, I'll be more than glad to work them out
> and merge it later, there's no "hard and fast deadline" anyone is asking
> for here.

The problem I have is that every time someone points out a fundamental
design issue you simply say "Why haven't you reviewed 13,000 lines of
code".

I haven't given it an in depth review for the same reason as if someone
posted 13,000 lines of "I've got an awesome new file system which uses a
FAT and 8.3 file names". There's some more pressing concerns to sort
first. The fact it's complex and hard to follow also doesn't encourage
review.

And the fact Al tried to read it and is asking for help really worries
me 8)

> 
> > Having something this controversial take place during the merge window
> > suggests its a bit premature to push in now.
> 
> "take place"?  Have you been ignoring these patches posted numerous
> times for many months?  This is the point in time to ask for code to be
> merged, just like any other code, nothing is special here.

Well - you've asked. I see two NACKs from people with great taste. So I
think the next step is to defer trying to submit it and work through the
fact that Al can't follow the locking, and other people don't believe the
security model is maintainable.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/