On Friday 04 May 2012 15:25:58 David Leverton wrote:
> Luca Barbato wrote:
> > On 03/05/12 16:18, Mike Frysinger wrote:
> >> you need to think bigger. Chromium supports joystick inputs (which come
> >> and go) for playing games in the browser, so udev makes sense.
> >
> > So is it using libudev to get that information? I guess would be
> > possible to patch it out, probably dbus would cover that base as well.
> >
> > (As soon I have some time I might dabble with a dbus integration for
> > mdev)
>
> If it really is just for joysticks etc it might be worth seeing if it
> can be made to use XInput instead. Maybe upstream had a specific reason
> not do it that way in the first place, but in general, X apps really
> shouldn't be touching the input devices directly.

why require X ?
-mike

Mike Frysinger wrote:

On Friday 04 May 2012 15:25:58 David Leverton wrote:

If it really is just for joysticks etc it might be worth seeing if it
can be made to use XInput instead. Maybe upstream had a specific reason
not do it that way in the first place, but in general, X apps really
shouldn't be touching the input devices directly.


why require X ?
-mike


I wasn't aware that Chromium on Linux supported anything else (and at
least the current ebuild has hard deps on X libraries), but when it is
running on X it ought to follow X conventions, even if it does something
else in other circumstances.

On Thu, May 03, 2012 at 09:22:11PM -0400, Mike Frysinger wrote

> we would have to make mdev available as a sep package then ... don't
> want busybox itself linking against anything beyond the C library.

Busybox, including its mdev functionality, is targetted at small and
embedded systems. I don't think that'll change, at least I hope it
doesn't. What could work is a shim or compatability layer that gets
called, and pre-processes requests and forwards them to mdev.

--
Walter Dnes <waltdnes@waltdnes.org>

On 04/05/12 14:35, Walter Dnes wrote:
> What could work is a shim or compatability layer that gets
> called, and pre-processes requests and forwards them to mdev.

That's my idea =)

lu

--

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

On Fri, May 04, 2012 at 12:39:40PM -0700, Luca Barbato wrote:
> On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> > On 5/4/12 8:21 PM, Mike Gilbert wrote:
> >> My 2 cents: The Chromium project really doesn't have any motivation to
> >> make it optional since their end product is Google Chrome and they
> >> target a given version of Ubuntu. I think a patch to make them
> >> optional might be accepted, but it probably isn't going to happen
> >> otherwise.
> >
> > Another point is that too many USE flags for such a big and complex
> > package as www-client/chromium would make testing much much harder, and
> > create many configurations upstream would not support.
>
> I'll check with upstream if that would be a huge problem for them, we
> have 6 useflags and we'd bump them to 8. Firefox has twice of them.
>
> If nobody else wants to I could have a look and see how hard is to make
> that nicer for our non-udev/non-dbus users on linux.

Why do we really care about non-udev and non-dbus users? It's only
going to get worse and worse if people don't want to use these core,
base libaries of the Linux "stack".

Yes, you can create a system without them, but in this day and age, why
would you want to? Are you saving memory? (nope), time? (nope),
complexity? (not really).

Remember, you are passing the complexity of insisting that you do not
want these things to the people managing the packages and trying to
support the system in so many different combinations. Why someone would
want to run Chromium on a system without udev or dbus is just looney...

greg k-h

On Fri, May 04, 2012 at 02:52:33PM -0700, Luca Barbato wrote:
> On 04/05/12 14:35, Walter Dnes wrote:
> > What could work is a shim or compatability layer that gets
> > called, and pre-processes requests and forwards them to mdev.
>
> That's my idea =)

and then, look, you have reimplemented udev.

{sigh}

On Fri, May 04, 2012 at 11:02:01AM -0700, Luca Barbato wrote:
> On 03/05/12 18:22, Mike Frysinger wrote:
> >> (As soon I have some time I might dabble with a dbus integration for mdev)
> >
> > we would have to make mdev available as a sep package then ... don't want
> > busybox itself linking against anything beyond the C library.
>
> The integration would be mdev -> shell -> dbus or mdev -> socket ->
> dbus. I consider dbus still not reliable for core services.

When was the last time dbus crashed on you?

And what would you consider "reliable" enough for "core services"? dbus
has proven itself over _many_ years to handle all of the issues that
something like this requires very well. It's a non-trivial thing to
implement and the authors of it have done a very good job, after
learning how to do it from other failed attempts at the same thing.

And what are you going to do when dbus moves into the kernel itself
(hint, it will be there soon)? How are you going to not use it then?

greg k-h

On Fri, May 04, 2012 at 05:58:24PM -0700, Greg KH wrote:
> On Fri, May 04, 2012 at 12:39:40PM -0700, Luca Barbato wrote:
> > On 04/05/12 11:37, "Paweł Hajdan, Jr." wrote:
> > > On 5/4/12 8:21 PM, Mike Gilbert wrote:
> > >> My 2 cents: The Chromium project really doesn't have any motivation to
> > >> make it optional since their end product is Google Chrome and they
> > >> target a given version of Ubuntu. I think a patch to make them
> > >> optional might be accepted, but it probably isn't going to happen
> > >> otherwise.
> > >
> > > Another point is that too many USE flags for such a big and complex
> > > package as www-client/chromium would make testing much much harder, and
> > > create many configurations upstream would not support.
> >
> > I'll check with upstream if that would be a huge problem for them, we
> > have 6 useflags and we'd bump them to 8. Firefox has twice of them.
> >
> > If nobody else wants to I could have a look and see how hard is to make
> > that nicer for our non-udev/non-dbus users on linux.
>
> Why do we really care about non-udev and non-dbus users? It's only
> going to get worse and worse if people don't want to use these core,
> base libaries of the Linux "stack".
>
> Yes, you can create a system without them, but in this day and age, why
> would you want to? Are you saving memory? (nope), time? (nope),
> complexity? (not really).
>
> Remember, you are passing the complexity of insisting that you do not
> want these things to the people managing the packages and trying to
> support the system in so many different combinations. Why someone would
> want to run Chromium on a system without udev or dbus is just looney...

s/Chromium/Chrome/

On 05/04/12 20:58, Greg KH wrote:
> Why do we really care about non-udev and non-dbus users? It's only
> going to get worse and worse if people don't want to use these core,
> base libaries of the Linux "stack".

I was under the impression that in order for there to be a Linux stack,
the Linux tree would need to include a userland in addition to a kernel.
Does the Linux Foundation plan to do this?

On Fri, May 04, 2012 at 09:27:05PM -0400, Richard Yao wrote:
> On 05/04/12 20:58, Greg KH wrote:
> > Why do we really care about non-udev and non-dbus users? It's only
> > going to get worse and worse if people don't want to use these core,
> > base libaries of the Linux "stack".
>
> I was under the impression that in order for there to be a Linux stack,
> the Linux tree would need to include a userland in addition to a kernel.

Huh? Don't you consider the kernel + glibc + xorg today a good "Linux
stack"? Isn't the "Android stack" another example of a good "Linux
stack"?

> Does the Linux Foundation plan to do this?

Not at all, the Linux Foundation is not doing any of this. The Linux
Foundation is a vendor-netural orginization that provides a "safe" place
for companies and the community to come together and collaborate on a
number of different projects. It also provides a place that sponsors a
few people to work in a vendor-netural way on projects they wish to work
on, with no say by the LF or anyone else on what they do with their
time. And it supports the kernel.org orginization in various ways as
well (financial and legal and administration.)

Hope this helps,

gre k-h