Mailing List Archive: Gentoo: Dev

Chromium bundled code

Index | Next | Previous | View Threaded

vapier at gentoo

Apr 30, 2012, 9:11 AM

Post #1 of 44 (743 views)
Permalink

Chromium bundled code

On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> doing it wrong. I don't like how Google develops Android in the dark,
> or that they bundle 1GB of third-party stuff in their Chromium source
> and distribute a favored binary-only derivative.

err, they distribute a Chromium source tarball, and their build system
includes flags to use the system versions of those bundled libs if you so
choose. i think this is a perfectly fine compromise.
-mike

Attachments:

signature.asc (0.82 KB)

rich0 at gentoo

Apr 30, 2012, 9:28 AM

Post #2 of 44 (736 views)
Permalink

Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. 狢 don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. 犲 think this is a perfectly fine compromise.

Must be a fairly new compromise - but glad to hear that they've come
along a bit.

Maybe their future Google Earth install package for Linux won't bundle wine. :)

In any case, I think this really just gets to my point - people who
develop FOSS aren't doing it with the express goal of making your life
difficult - they just don't always have the same itches. If you help
them out or ask NICELY sometimes they'll even help scratch yours.

Rich

mattst88 at gentoo

Apr 30, 2012, 9:32 AM

Post #3 of 44 (734 views)
Permalink

Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> doing it wrong. 狢 don't like how Google develops Android in the dark,
>> or that they bundle 1GB of third-party stuff in their Chromium source
>> and distribute a favored binary-only derivative.
>
> err, they distribute a Chromium source tarball, and their build system
> includes flags to use the system versions of those bundled libs if you so
> choose. 犲 think this is a perfectly fine compromise.
> -mike

It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
libraries, and still has TODOs in place to use the system's ffmpeg,
hunspell, (Open?)SSL, SQLite, and libvpx.

vapier at gentoo

Apr 30, 2012, 10:30 AM

Post #4 of 44 (729 views)
Permalink

Re: Chromium bundled code [In reply to]

On Monday 30 April 2012 12:32:35 Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
> >> doing it wrong. I don't like how Google develops Android in the dark,
> >> or that they bundle 1GB of third-party stuff in their Chromium source
> >> and distribute a favored binary-only derivative.
> >
> > err, they distribute a Chromium source tarball, and their build system
> > includes flags to use the system versions of those bundled libs if you so
> > choose. i think this is a perfectly fine compromise.
>
> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries

to be sure the system ones get used

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

it's on going work :). ffmpeg/libvpx are a bit harder as Chromium syncs faster
than they make releases i believe.
-mike

Attachments:

signature.asc (0.82 KB)

floppym at gentoo

Apr 30, 2012, 10:42 AM

Post #5 of 44 (729 views)
Permalink

Re: Chromium bundled code [In reply to]

On Mon, Apr 30, 2012 at 1:30 PM, Mike Frysinger <vapier [at] gentoo> wrote:
> On Monday 30 April 2012 12:32:35 Matt Turner wrote:
>> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger wrote:
>> > On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>> >> doing it wrong. �I don't like how Google develops Android in the dark,
>> >> or that they bundle 1GB of third-party stuff in their Chromium source
>> >> and distribute a favored binary-only derivative.
>> >
>> > err, they distribute a Chromium source tarball, and their build system
>> > includes flags to use the system versions of those bundled libs if you so
>> > choose. �i think this is a perfectly fine compromise.
>>
>> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
>> libraries
>
> to be sure the system ones get used
>
>> and still has TODOs in place to use the system's ffmpeg,
>> hunspell, (Open?)SSL, SQLite, and libvpx.
>
> it's on going work :). �ffmpeg/libvpx are a bit harder as Chromium syncs faster
> than they make releases i believe.
> -mike

Right. Generally, the bundled ffmpeg does not correspond to an
official upstream release.

ffmpeg upstream is not afraid of making API changes, so it has proven
quite difficult to make chromium work with all versions on ffmpeg in
portage, plus the bundled snapshot. When we were using the system lib,
it would break nearly every time a new major version of chromium was
forked.

phajdan.jr at gentoo

May 3, 2012, 2:34 AM

Post #6 of 44 (728 views)
Permalink

Re: Chromium bundled code [In reply to]

On 4/30/12 6:32 PM, Matt Turner wrote:
> On Mon, Apr 30, 2012 at 12:11 PM, Mike Frysinger <vapier [at] gentoo> wrote:
>> On Monday 30 April 2012 12:00:59 Rich Freeman wrote:
>>> doing it wrong. I don't like how Google develops Android in the dark,
>>> or that they bundle 1GB of third-party stuff in their Chromium source
>>> and distribute a favored binary-only derivative.
>>
>> err, they distribute a Chromium source tarball, and their build system
>> includes flags to use the system versions of those bundled libs if you so
>> choose. i think this is a perfectly fine compromise.

Right, and the source tarball is ~175 MB. It's not perfect, but it's
also far from 1 GB. The bundled libraries are included in the tarball.

> It looks like chromium-20.0.1115.1.ebuild removes 45 bundled
> libraries.

Note that the list in the ebuild is about _excluding_ bundled libraries,
i.e. the directories listed are removed and everything else is removed.

I'm generally co-operating with upstream (also as part of that upstream,
but with limited resources at least for now) so that there are options
to use system libraries, and what's left is non-trivial to unbundle
(e.g. mesa) but it should be unbundled at some point.

> and still has TODOs in place to use the system's ffmpeg,
> hunspell, (Open?)SSL, SQLite, and libvpx.

Yes, the TODOs can definitely tell you what's left there. The list is
not comprehensive though.

Ah, and help is always welcome - with unbundling libraries, gcc-4.7
porting, and other things. Feel free to send your thoughts/questions to
chromium [at] g

Pawe�

Attachments:

signature.asc (0.20 KB)

phajdan.jr at gentoo

May 3, 2012, 2:37 AM

Post #7 of 44 (723 views)
Permalink

Re: Chromium bundled code [In reply to]

On 4/30/12 7:42 PM, Mike Gilbert wrote:
> ffmpeg upstream is not afraid of making API changes, so it has proven
> quite difficult to make chromium work with all versions on ffmpeg in
> portage, plus the bundled snapshot. When we were using the system lib,
> it would break nearly every time a new major version of chromium was
> forked.

Right. Eventually I'd like to create an ffmpeg compatibility layer in
Chromium, so that all Chromium-specific code would talk to it, and the
layer would know how to handle (at compile time) different versions of
ffmpeg.

Also, the browser binary should really just link directly to ffmpeg
libraries instead of using dlopen. I also plan to change that.

Attachments:

signature.asc (0.20 KB)

rich0 at gentoo

May 3, 2012, 8:28 AM

Post #8 of 44 (723 views)
Permalink

Re: Chromium bundled code [In reply to]

On Thu, May 3, 2012 at 5:34 AM, "Pawe� Hajdan, Jr."
<phajdan.jr [at] gentoo> wrote:
>
> Right, and the source tarball is ~175 MB. It's not perfect, but it's
> also far from 1 GB. The bundled libraries are included in the tarball.

I was thinking about the unpacked size - which is 1001M according to
du for chromium-18.0.1025.168.tar.bz2. That's a lot of source code...

However, my whole point wasn't to throw stones at the chromium team -
I think that they've been doing a great job of fixing this problem,
and will continue to do so. I just was pointing out that Google's
practice of bundling dependencies wasn't to my liking, but that I
wasn't going to give them too much of a hard time precisely because
I'm not being part of the solution.

Rich

waltdnes at waltdnes

May 3, 2012, 2:39 PM

Post #9 of 44 (717 views)
Permalink

Re: Chromium bundled code [In reply to]

On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote

> However, my whole point wasn't to throw stones at the chromium team -
> I think that they've been doing a great job of fixing this problem,
> and will continue to do so. I just was pointing out that Google's
> practice of bundling dependencies wasn't to my liking, but that I
> wasn't going to give them too much of a hard time precisely because
> I'm not being part of the solution.

I think Chromium's problem is that it's based on Chrome. And Google
is "pulling an AOL" by trying to turn Chrome into an OS for its
Chromebooks. To paraphrase the old emacs joke... Chrom(e/ium) is a
mediocre OS that lacks a lightweight web browser. I just did a
"pretend" build for Chromium. I fail to understand why a *WEB BROWSER*
needs elfutils and dbus and udev as hard-coded dependancies. The udev
dependancy is a show stopper for me, as I've migrated over to mdev. See
https://wiki.gentoo.org/wiki/Mdev That page is now mostly other
people's contributions. I was the rabble-rouser who started it.

--
Walter Dnes <waltdnes [at] waltdnes>

vapier at gentoo

May 3, 2012, 4:18 PM

Post #10 of 44 (827 views)
Permalink

Re: Chromium bundled code [In reply to]

On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> I think Chromium's problem is that it's based on Chrome.

you've got that wrong. Chrome is based on Chromium.

> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks.

ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
to provide a slim/secure Linux base in which you run Chrome.

> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
> hard-coded dependancies.

you need to think bigger. Chromium supports joystick inputs (which come and
go) for playing games in the browser, so udev makes sense. it also supports
looking up your location, detecting when the network comes up/down, and
kde/gnome password stores, all of which require dbus. and with nacl, you're
loading ELF objects, so libelf makes sense.

really though, if you don't like Chrome, then don't use it. many people do.
-mike

Attachments:

signature.asc (0.82 KB)

lu_zero at gentoo

May 3, 2012, 5:49 PM

Post #11 of 44 (727 views)
Permalink

Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/05/12 16:18, Mike Frysinger wrote:
> On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
>> I think Chromium's problem is that it's based on Chrome.
>
> you've got that wrong. Chrome is based on Chromium.
>
>> And Google is "pulling an AOL" by trying to turn Chrome into an OS for its
>> Chromebooks.
>
> ChromeOS and Chrome are run as semi-separate projects. the former uses Gentoo
> to provide a slim/secure Linux base in which you run Chrome.
>
>> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and udev as
>> hard-coded dependancies.
>
> 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)

lu

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+jJ5UACgkQ6Ex4woTpDjQOtQCZAYnPNGSZ/qlukltSyLL+zACm
vuYAoJp6uvjatUzQrJRK53Hl9kQD9IiN
=onw7
-----END PGP SIGNATURE-----

vapier at gentoo

May 3, 2012, 6:22 PM

Post #12 of 44 (723 views)
Permalink

Re: Chromium bundled code [In reply to]

On Thursday 03 May 2012 20:49:25 Luca Barbato wrote:
> On 03/05/12 16:18, Mike Frysinger wrote:
> > On Thursday 03 May 2012 17:39:30 Walter Dnes wrote:
> >> I fail to understand why a *WEB BROWSER* needs elfutils and dbus and
> >> udev as hard-coded dependancies.
> >
> > 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.

i'm not sure that info is broadcasted over dbus. at any rate, if it is, i'm
not sure that would gain traction upstream unless it was an improvement. and
if it's not going upstream, i don't Pawe� is keen on maintaining it locally.

> (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.
-mike

Attachments:

signature.asc (0.82 KB)

antarus at gentoo

May 4, 2012, 1:37 AM

Post #13 of 44 (712 views)
Permalink

Re: Chromium bundled code [In reply to]

On Thu, May 3, 2012 at 11:39 PM, Walter Dnes <waltdnes [at] waltdnes> wrote:
> On Thu, May 03, 2012 at 11:28:49AM -0400, Rich Freeman wrote
>
>> However, my whole point wasn't to throw stones at the chromium team -
>> I think that they've been doing a great job of fixing this problem,
>> and will continue to do so. �I just was pointing out that Google's
>> practice of bundling dependencies wasn't to my liking, but that I
>> wasn't going to give them too much of a hard time precisely because
>> I'm not being part of the solution.
>
> �I think Chromium's problem is that it's based on Chrome. �And Google
> is "pulling an AOL" by trying to turn Chrome into an OS for its
> Chromebooks. �To paraphrase the old emacs joke... Chrom(e/ium) is a
> mediocre OS that lacks a lightweight web browser. �I just did a
> "pretend" build for Chromium. �I fail to understand why a *WEB BROWSER*

I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
totally OK and you are free to use whatever software you prefer. I
somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
dbus / etc requirements.

Disclaimer, I work at Google (but not on any Chrom{e,ium}(OS) related projects.)

-A

> needs elfutils and dbus and udev as hard-coded dependancies. �The udev
> dependancy is a show stopper for me, as I've migrated over to mdev. �See
> https://wiki.gentoo.org/wiki/Mdev �That page is now mostly other
> people's contributions. �I was the rabble-rouser who started it.
>
> --
> Walter Dnes <waltdnes [at] waltdnes>
>

lu_zero at gentoo

May 4, 2012, 11:02 AM

Post #14 of 44 (716 views)
Permalink

Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

> -mike

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kGZkACgkQ6Ex4woTpDjSAhgCeLCi65aZru86eamoOEVQzqXrH
mwgAoOX538fSV09WkUYApNL33+3uf4RX
=nnLz
-----END PGP SIGNATURE-----

lu_zero at gentoo

May 4, 2012, 11:03 AM

Post #15 of 44 (706 views)
Permalink

Re: Chromium bundled code [In reply to]

On 04/05/12 01:37, Alec Warner wrote:
> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
> totally OK and you are free to use whatever software you prefer. I
> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
> dbus / etc requirements.

If dbus and libudev are just for fringe features might be nice disable
them. I wonder if there isn't already a setting for it. chrome for
android won't use them anyway.

--

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

floppym at gentoo

May 4, 2012, 11:21 AM

Post #16 of 44 (707 views)
Permalink

Re: Chromium bundled code [In reply to]

On Fri, May 4, 2012 at 2:03 PM, Luca Barbato <lu_zero [at] gentoo> wrote:
> On 04/05/12 01:37, Alec Warner wrote:
>> I would argue that the Chrome Team's idea of what a 'WEB BROWSER' is
>> and your idea of what a 'WEB BROWSER' is are vastly divergent. That is
>> totally OK and you are free to use whatever software you prefer. I
>> somehow doubt Chrom{e,ium} is losing tons of users due to their udev /
>> dbus / etc requirements.
>
> If dbus and libudev are just for fringe features might be nice disable
> them. I wonder if there isn't already a setting for it. chrome for
> android won't use them anyway.
>

I don't see a user-controllable setting for dbus or udev. Rather, it
checks for OS == "Linux".

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.

phajdan.jr at gentoo

May 4, 2012, 11:35 AM

Post #17 of 44 (712 views)
Permalink

Re: Chromium bundled code [In reply to]

On 5/4/12 8:02 PM, Luca Barbato wrote:
> I consider dbus still not reliable for core services.

Just curious - why? I just have no idea about how dbus works or what are
possible problems with it.

Attachments:

signature.asc (0.20 KB)

phajdan.jr at gentoo

May 4, 2012, 11:37 AM

Post #18 of 44 (707 views)
Permalink

Re: Chromium bundled code [In reply to]

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.

Attachments:

signature.asc (0.20 KB)

lu_zero at gentoo

May 4, 2012, 12:18 PM

Post #19 of 44 (713 views)
Permalink

Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/05/12 11:35, "Pawe� Hajdan, Jr." wrote:
> On 5/4/12 8:02 PM, Luca Barbato wrote:
>> I consider dbus still not reliable for core services.
>
> Just curious - why? I just have no idea about how dbus works or what are
> possible problems with it.

About all the integrations I know of crash if the daemon crashes and the
daemon itself tended to be frail. I hadn't checked lately if it improved
since all my usage for it is limited.

Anyway for core services I'm sold to the principle of the least
complexity and maximum separation, so that replacing/updating dbus won't
force me to reboot my system.

lu

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kK4MACgkQ6Ex4woTpDjQKkACfWepG+ppIl/uapi9JjMlsF0fh
8IAAoIvzZ1kq0dJNo8q+kyXVayEZRTNM
=LST6
-----END PGP SIGNATURE-----

levertond at googlemail

May 4, 2012, 12:25 PM

Post #20 of 44 (707 views)
Permalink

Re: Chromium bundled code [In reply to]

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.

lu_zero at gentoo

May 4, 2012, 12:39 PM

Post #21 of 44 (706 views)
Permalink

Re: Chromium bundled code [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

lu

- --

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+kMHwACgkQ6Ex4woTpDjTTAgCfXtMJFJjB5ZH08u0Nb7yKmkqv
/GwAoNejWgUcHaMWnD6e8Bgr/+V/cYDA
=CCQe
-----END PGP SIGNATURE-----

vapier at gentoo

May 4, 2012, 12:41 PM

Post #22 of 44 (708 views)
Permalink

Re: Chromium bundled code [In reply to]

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

Attachments:

signature.asc (0.82 KB)

levertond at googlemail

May 4, 2012, 12:48 PM

Post #23 of 44 (709 views)
Permalink

Re: Chromium bundled code [In reply to]

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.

waltdnes at waltdnes

May 4, 2012, 2:35 PM

Post #24 of 44 (709 views)
Permalink

Re: Chromium bundled code [In reply to]

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 [at] waltdnes>

lu_zero at gentoo

May 4, 2012, 2:52 PM

Post #25 of 44 (706 views)
Permalink

Re: Chromium bundled code [In reply to]

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

gregkh at gentoo

May 4, 2012, 5:58 PM

Post #26 of 44 (268 views)
Permalink

Re: Chromium bundled code [In reply to]

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

gregkh at gentoo

May 4, 2012, 5:59 PM

Post #27 of 44 (268 views)
Permalink

Re: Chromium bundled code [In reply to]

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}

gregkh at gentoo

May 4, 2012, 6:02 PM

Post #28 of 44 (271 views)
Permalink

Re: Chromium bundled code [In reply to]

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

gregkh at gentoo

May 4, 2012, 6:06 PM

Post #29 of 44 (271 views)
Permalink

Re: Chromium bundled code [In reply to]

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/

ryao at cs

May 4, 2012, 6:27 PM

Post #30 of 44 (270 views)
Permalink

Re: Chromium bundled code [In reply to]

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?

Attachments:

signature.asc (0.88 KB)

gregkh at gentoo

May 4, 2012, 6:33 PM

Post #31 of 44 (269 views)
Permalink

Re: Chromium bundled code [In reply to]

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

chithanh at gentoo

May 4, 2012, 6:50 PM

Post #32 of 44 (271 views)
Permalink

Re: Chromium bundled code [In reply to]

Greg KH schrieb:
> 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"?

I'd say that Android is an operating system based on Linux. It is not
'the Linux "stack"'.
I think he was wondering whether the lock-in between dbus, udev and the
Linux kernel will reach proportions where they will be distributed in
one source tree.

Best regards,
Ch穩-Thanh Christopher Nguy廙�n

vapier at gentoo

May 4, 2012, 7:00 PM

Post #33 of 44 (270 views)
Permalink

Re: Chromium bundled code [In reply to]

On Friday 04 May 2012 21:06:52 Greg KH wrote:
> On Fri, May 04, 2012 at 05:58:24PM -0700, Greg KH wrote:
> > 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/

for the purposes of your point, either works
-mike

Attachments:

signature.asc (0.82 KB)

rich0 at gentoo

May 4, 2012, 7:06 PM

Post #34 of 44 (269 views)
Permalink

Re: Chromium bundled code [In reply to]

On Fri, May 4, 2012 at 9:50 PM, Ch穩-Thanh Christopher Nguy廙�n
<chithanh [at] gentoo> wrote:
> I'd say that Android is an operating system based on Linux. It is not
> 'the Linux "stack"'.
> I think he was wondering whether the lock-in between dbus, udev and the
> Linux kernel will reach proportions where they will be distributed in
> one source tree.

Well, I think that all of this is at the heart of the debate. I don't
see whether the source trees are merged as being terribly important -
the issue is whether the level of integration makes them difficult to
peel apart.

This is just the vertical integration debate all over again. If you
want to use gnome, thou shalt use systemd. If you want to use
Chromium, thou shalt use udev, and so on. I can't wait until we hit
the point where if you want to use your favorite browser you have to
install the maintainer's favorite DE, sysvinit, etc.

The only solution I see to getting back to the "unix way" is to agree
upon standard APIs, but I think that is many years off. Most of these
technologies are very new, and rapidly evolving. Google themselves
have shown with platforms like Android that compatibility is not of
terrible importance to them beyond the application API (how many times
have they broken the camera driver binary interface?), and of course
Linux is famous for breaking driver-level binary interfaces, though
this is mitigated by the fact that outside of Android almost everybody
makes their drivers open-source, or they actually support their
drivers for more than six months.

The next year or two will be an interesting experiment for the Linux
community. Will the "unix way" prevail, or does the future lie in
highly integrated tools, that generally do not interoperate, but which
provide much greater functionality?

Rich

rdalek1967 at gmail

May 4, 2012, 7:11 PM

Post #35 of 44 (269 views)
Permalink

Re: Chromium bundled code [In reply to]

Greg KH wrote:
> 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
>
>

This question is not directed at me but I'll give a response to my
experience a few months ago. I woke up to my system fans blowing like
crazy. Trust me, if you can hear noise on a HAF-932, they are spinning
pretty good. It was mostly air I was hearing but anyway. I use KDE and
have Konsole open at all times. I switched to the desktop with it,
after noticing on Gkrellm that my CPU was maxed out and that almost all
my ram was in use and some swap too. I don't mean cached or anything
either, I mean actively in use.

At any rate, when it finally switched to the desktop with Konsole on it,
which took a bit, I ran top. At the top for both CPU and memory usage
was dbus. I tried to restart the dbus service, thinking it would kill
it and restart without all the ram and CPU usage. I could then logout
and back in, maybe. I never got my prompt back and it never showed dbus
as stopped either.

I then switched to a console. I did a 'rc boot' and it was slowly
switching to it and did but it couldn't stop the dbus service. I just
typed in reboot and let it restart from scratch.

Was it dbus itself, I dunno for sure. I am sure it was dbus that was
maxing out my CPU and ram. I did recompile dbus after the reboot and it
has not done it since. If I could reproduce it or had more info, I
would have mentioned it when it happened. I'm thinking rays from Mars
or something. ;-) It wasn't hardware either. This system has been
running fine ever since.

By the way, I have 16Gbs of ram. If I recall correctly, dbus was using
over 14Gbs of ram and something was using swap. Keep in mind, I had KDE
running with Seamonkey, Konsole, Konqueror and a couple other apps open.
I use about 1.5Gbs when my desktop is in normal use. Swappiness is set
to 20. In other words, only use swap when it is getting deep. It was
using half my swap so it must have been pretty deep.

So, even dbus can have a bad day at times. Sure wish I knew what caused
it tho.

Dale

:-) :-)

--
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

ryao at cs

May 5, 2012, 9:32 AM

Post #36 of 44 (270 views)
Permalink

Re: Chromium bundled code [In reply to]

On 05/04/12 21:33, Greg KH wrote:
> 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"?

glibc and xorg can run on top of Linux, but I would not call them a
Linux stack. glibc is the C standard library for the GNU operating
system while xorg is a windowing system intended for UNIX operating
systems. People have them working on top of Linux, but people have them
working on top of other kernels too. The Debian developers have both
components working on top of FreeBSD's kernel as well as HURD, which is
glibc's native kernel.

As for the Android stack, it is currently used on Linux, but nothing
prevents it from being used on other kernels. In specific, both Solaris
and FreeBSD the ability to run software built against the Linux kernel
ABI. If one were sufficiently motivated, it should be possible to run
the Android stack on either of them.

My understanding of a stack is that it generally includes a kernel, a
libc, a C compiler, an assembler, a linker, a bootloader, an init
system, a getty implementation, a command shell, a text editor and some
basic UNIX commands (e.g. cp, mv, rm). There is some userland software
in the Linux tree in ./usr and ./tools, but aside from the kernel, I
cannot find anything that constitutes a stack, or even a stack minus a
few components.

Plenty of regressions stem from using other projects' stacks on Linux.
The following regression was particularly painful:

https://bugzilla.redhat.com/show_bug.cgi?id=638477

I would love to use the Linux stack on my Linux systems to avoid such
regressions, but I cannot find one. If one exists, please let me know.

Attachments:

signature.asc (0.88 KB)

ciaran.mccreesh at googlemail

May 5, 2012, 9:35 AM

Post #37 of 44 (271 views)
Permalink

Re: Chromium bundled code [In reply to]

On Fri, 4 May 2012 18:02:05 -0700
Greg KH <gregkh [at] gentoo> wrote:
> And what are you going to do when dbus moves into the kernel itself
> (hint, it will be there soon)?

Why stop at dbus? Why isn't libxml2 in the kernel yet?

--
Ciaran McCreesh

Attachments:

signature.asc (0.19 KB)

gregkh at gentoo

May 5, 2012, 10:53 AM

Post #38 of 44 (267 views)
Permalink

Re: Chromium bundled code [In reply to]

On Sat, May 05, 2012 at 05:35:22PM +0100, Ciaran McCreesh wrote:
> On Fri, 4 May 2012 18:02:05 -0700
> Greg KH <gregkh [at] gentoo> wrote:
> > And what are you going to do when dbus moves into the kernel itself
> > (hint, it will be there soon)?
>
> Why stop at dbus? Why isn't libxml2 in the kernel yet?

Because kernel developers are merely crazy, not insane.

waltdnes at waltdnes

May 7, 2012, 3:23 PM

Post #39 of 44 (248 views)
Permalink

Re: Chromium bundled code [In reply to]

On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> 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}

Actually, more like what udev *USED TO BE*, namely a simple devicei
manager.

--
Walter Dnes <waltdnes [at] waltdnes>

waltdnes at waltdnes

May 7, 2012, 3:32 PM

Post #40 of 44 (302 views)
Permalink

Re: Chromium bundled code [In reply to]

On Fri, May 04, 2012 at 06:06:52PM -0700, Greg KH wrote
> > 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/

Ahem...

=====================================================================
waltdnes [at] d53 ~ $ USE="icu" emerge -pv chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "sys-fs/udev" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-fs/udev-9999::gentoo (masked by: package.mask, missing keyword)
/etc/portage/package.mask:

- sys-fs/udev-182-r3::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-182-r2::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-171-r5::gentoo (masked by: package.mask)
- sys-fs/udev-164-r2::gentoo (masked by: package.mask)
- sys-fs/udev-151-r4::gentoo (masked by: package.mask)
- sys-fs/udev-149::gentoo (masked by: package.mask)
- sys-fs/udev-146-r1::gentoo (masked by: package.mask)
- sys-fs/udev-141-r1::gentoo (masked by: package.mask, ~x86 keyword)
- sys-fs/udev-141::gentoo (masked by: package.mask)
- sys-fs/udev-124-r2::gentoo (masked by: package.mask)
- sys-fs/udev-124-r1::gentoo (masked by: package.mask)
- sys-fs/udev-119::gentoo (masked by: package.mask)
- sys-fs/udev-115-r1::gentoo (masked by: package.mask)
- sys-fs/udev-114::gentoo (masked by: package.mask)

(dependency required by "www-client/chromium-18.0.1025.151" [ebuild])
(dependency required by "chromium" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
=====================================================================

OK, I temporarily unmask udev...

=====================================================================
waltdnes [at] d53 ~ $ USE="icu" emerge -pv chromium

These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=sys-apps/dbus-1.4.16" have been masked.
!!! One of the following masked packages is required to complete your request:
- sys-apps/dbus-1.4.20::gentoo (masked by: package.mask)
/etc/portage/package.mask:

- sys-apps/dbus-1.4.18::gentoo (masked by: package.mask)
- sys-apps/dbus-1.4.16-r2::gentoo (masked by: package.mask, ~x86
keyword)
- sys-apps/dbus-1.4.16::gentoo (masked by: package.mask)

(dependency required by "dev-libs/dbus-glib-0.98" [ebuild])
(dependency required by "www-client/chromium-18.0.1025.151" [ebuild])
(dependency required by "chromium" [argument])
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.
=====================================================================

QED.

--
Walter Dnes <waltdnes [at] waltdnes>

tester at gentoo

May 7, 2012, 4:16 PM

Post #41 of 44 (249 views)
Permalink

Re: Chromium bundled code [In reply to]

On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
> > 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}
>
> Actually, more like what udev *USED TO BE*, namely a simple devicei
> manager.

Maybe Greg understands how udev was and how it should be better than you
do, since he wrote it.

--
Olivier Cr礙te
tester [at] gentoo
Gentoo Developer

Attachments:

signature.asc (0.19 KB)

patrick at gentoo

May 7, 2012, 5:46 PM

Post #42 of 44 (250 views)
Permalink

Re: Chromium bundled code [In reply to]

On 05/08/12 07:16, Olivier Cr礙te wrote:
> On Mon, 2012-05-07 at 18:23 -0400, Walter Dnes wrote:
>> On Fri, May 04, 2012 at 05:59:45PM -0700, Greg KH wrote
>>> 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}
>> Actually, more like what udev *USED TO BE*, namely a simple devicei
>> manager.
> Maybe Greg understands how udev was
... and of course the horrors that were called "devfs" and such - we
remember :)
> and how it should be better than you
> do,
err, that's bad. Maybe I know my needs better than other people? Maybe
my needs don't completely overlap with those of other people. Maybe
their vision of a tightly coupled everything doesn't even cover my
usecases nicely ...
> since he wrote it.
>
>
Classical argumentum ad verecundiam, you win a cookie.

lu_zero at gentoo

May 7, 2012, 7:54 PM

Post #43 of 44 (251 views)
Permalink

Re: Chromium bundled code [In reply to]

On 04/05/12 18:02, Greg KH wrote:

> When was the last time dbus crashed on you?

Last time I used with bluez? I think about few months ago, I hadn't time
to debug the issue and I tend not to use stuff I known broken.

I know that's a chicken egg issue =|

I'm not sure if connman hanging randomly is related to dbus or connman
itself, again I hadn't had time to check what's exactly wrong.

> And what would you consider "reliable" enough for "core services"?

No dependency beside libc.

> 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.

Yet it crashes in some situations. My fault for not helping debugging
them I guess. Again, I had something more interesting to do.

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

Disabling it if I don't need it, as everybody in the world does disable
the posix message queues?

> How are you going to not use it then?

I guess freebsd is still a supported platform for enlightenment and all
the programs I use.

lu

--

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

lu_zero at gentoo

May 7, 2012, 8:57 PM

Post #44 of 44 (247 views)
Permalink

Re: Chromium bundled code [In reply to]

On 04/05/12 17:59, Greg KH wrote:
> 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.
>

I think that's the whole point of the exercise.

lu

--

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads