Re: DeviceKit and /usr
Giacomo A. Catenazzi wrote: Case 2: char *foo = g_strdup_printf (%s equals %i, somestring, someint); Pick your choice. Case 1, please. Either case 2 fails to handle the allocation error, or glib is doing its own abort. Neither is acceptable. and BTW the function seems not documented (I don't find the relevant manpage). FWIW glib and GTK+, the whole GNOME stack, and more, are using gtk-doc to document their API, you will find the generated documentation in HTML form in libglib2.0-doc. And there is http://bugzilla.gnome.org/show_bug.cgi?id=467488 where the generation of manpages is discussed. Frederic -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le mardi 08 septembre 2009 à 10:55 +0200, Bernhard R. Link a écrit : Often there is something sensible: Wait till more memory is available or just make the operation needing so much memory fail. If it’s an operation that specifically requires much memory, Glib provides g_try_*alloc functions for that. However, when allocations start failing for string manipulation operations, the application is doomed. It's all a matter of context: for some graphical program it is usually reasonable to not care and just abort. For some system daemon not automatically respawned terminating because of some transient condition is just a bug. (Even if Linux makes it not very easy to catch all such conditions, not handling accordingly if one detects something like that has no excuse but laziness). When the daemon gets in this situation, it’s very likely to be the first target for the OOM killer. Note that most high-level languages are also going to simply dump an unhandled exception when the process gets out of memory. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
* Josselin Mouette j...@debian.org, 2009-09-08, 10:06: Case 1, please. Either case 2 fails to handle the allocation error, or glib is doing its own abort. Neither is acceptable. Yeah, sure. As if there was anything more sensible to do than aborting when a memory allocation fails. When this happens under Linux, the application will end up OOM-killed really soon anyway. Unless there is more physical memory than virtual memory (hint: ulimit -v). -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a écrit : Steve Langasek wrote: Case 1, please. Either case 2 fails to handle the allocation error, or glib is doing its own abort. Neither is acceptable. Yeah, sure. As if there was anything more sensible to do than aborting when a memory allocation fails. When this happens under Linux, the application will end up OOM-killed really soon anyway. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
* Josselin Mouette j...@debian.org [090908 10:45]: Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a Steve Langasek wrote: Case 1, please. Either case 2 fails to handle the allocation error, or glib is doing its own abort. Neither is acceptable. Yeah, sure. As if there was anything more sensible to do than aborting when a memory allocation fails. When this happens under Linux, the application will end up OOM-killed really soon anyway. Often there is something sensible: Wait till more memory is available or just make the operation needing so much memory fail. It's all a matter of context: for some graphical program it is usually reasonable to not care and just abort. For some system daemon not automatically respawned terminating because of some transient condition is just a bug. (Even if Linux makes it not very easy to catch all such conditions, not handling accordingly if one detects something like that has no excuse but laziness). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Twas brillig at 11:00:07 08.09.2009 UTC+02 when j...@debian.org did gyre and gimble: JM If it’s an operation that specifically requires much memory, Glib JM provides g_try_*alloc functions for that. JM However, when allocations start failing for string manipulation JM operations, the application is doomed. Freeing caches or correctly finishing (e.g. rolling back current file operation) and shutting down are the possible actions in case of lack of memory. JM Note that most high-level languages are also going to simply dump JM an unhandled exception when the process gets out of memory. Yes, and it can be handled (though rarely do). -- http://fossarchy.blogspot.com/ pgphc7qY3pgzf.pgp Description: PGP signature
Re: DeviceKit and /usr
* Josselin Mouette j...@debian.org [090908 11:00]: Le mardi 08 septembre 2009 à 10:55 +0200, Bernhard R. Link a écrit : Often there is something sensible: Wait till more memory is available or just make the operation needing so much memory fail. If it???s an operation that specifically requires much memory, Glib provides g_try_*alloc functions for that. However, when allocations start failing for string manipulation operations, the application is doomed. A lazily implemented application is doomed. It's all a matter of context: for some graphical program it is usually reasonable to not care and just abort. For some system daemon not automatically respawned terminating because of some transient condition is just a bug. (Even if Linux makes it not very easy to catch all such conditions, not handling accordingly if one detects something like that has no excuse but laziness). When the daemon gets in this situation, it???s very likely to be the first target for the OOM killer. As I said, Linux is not especially good in out of memory handling. But there are (still much improveable) ways to influence OOM killer and to not make Linux give your program memory not yet available. Not handling this means increasing the cases for failure for no better reason but laziness. Note that most high-level languages are also going to simply dump an unhandled exception when the process gets out of memory. Either you can catch that exception and write programs that continue running and will work again if there is enough memory, or that language is not suitable to write system daemons with it. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette j...@debian.org writes: Le lundi 07 septembre 2009 à 20:00 +0200, Giacomo A. Catenazzi a écrit : Steve Langasek wrote: Case 1, please. Either case 2 fails to handle the allocation error, or glib is doing its own abort. Neither is acceptable. Yeah, sure. As if there was anything more sensible to do than aborting when a memory allocation fails. When this happens under Linux, the application will end up OOM-killed really soon anyway. Even so, case 1 documents the author's intentions. Case 2 leaves us wondering whether the abort is intentional or not. Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit : Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. If a memory allocation failed while you were manipulating strings (an operation with very low requirements), you are not likely to obtain enough memory to even display an error message. Frankly, I prefer to be sure that the process will crash properly in extreme cases. And more importantly, not having to handle return codes for every function is much less prone to programming errors; something that is shared by most Glib string utility functions. And programming errors in string manipulations represent an important part of security bugs. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
Josselin Mouette wrote: Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit : Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. If a memory allocation failed while you were manipulating strings (an operation with very low requirements), you are not likely to obtain enough memory to even display an error message. Frankly, I prefer to be sure that the process will crash properly in extreme cases. And more importantly, not having to handle return codes for every function is much less prone to programming errors; something that is shared by most Glib string utility functions. And programming errors in string manipulations represent an important part of security bugs. We are talking with low-level application. Such application must be safer (and clean-up the environment and lock in case of errors). We prefer a limited system then a unstable stystem (half initialized). We are using the wrong tool for such task: glib is made for the other end of application, not for daemon and basic utilities, where the requirement are different. And the entire discussion is about this topic, not about if glib is good or not. PS: I'm thinking on old low-mem computer (e.g. for schools) where Linux is the only alternative to the trash. ciao cate -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Tue, Sep 08, 2009 at 01:16:08PM +0200, Josselin Mouette wrote: Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit : Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. If a memory allocation failed while you were manipulating strings (an operation with very low requirements), you are not likely to obtain enough memory to even display an error message. You probably still have enough memory available on the stack to handle memory allocation errors on the heap. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette j...@debian.org writes: Le mardi 08 septembre 2009 à 13:00 +0200, Bjørn Mork a écrit : Trusting a library to do all your error handling and cleanup is not good style IMHO. In addition to the lack of self-documenting source, it often leave you with the meaningless generic error messages some OSes are so full of. Applications doing their own error handling are in a much better position to provide specific meaningfull error messages to the user. If a memory allocation failed while you were manipulating strings (an operation with very low requirements), you are not likely to obtain enough memory to even display an error message. I'm with Josselin on this. The daemons I write die when they run out of memory for things like string manipulation. The library that I use for such error handling supports a termination routine that can be called in that case to do an emergency shutdown of resources, but the daemon still then exits. Libraries are another matter, of course, and should instead return failure codes to the calling application for the application to deal with as it choses. But applications should feel free to terminate when they can't even allocate small amounts of memory for string manipulation. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : It rather needs to raise the question why simple low-level tools use something like libglib? I’d rather raise the question why each of our simple low-level tools implement its data structures and basic routines in its own fashion, leading to bugs and security issues sometimes, instead of re-using the ones from Glib. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
Josselin Mouette j...@debian.org writes: Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : It rather needs to raise the question why simple low-level tools use something like libglib? I’d rather raise the question why each of our simple low-level tools implement its data structures and basic routines in its own fashion, leading to bugs and security issues sometimes, instead of re-using the ones from Glib. Oh, come on... Exactly what does glib add here: #define G_GNUC_PRINTF( format_idx, arg_idx )\ __attribute__((__format__ (__printf__, format_idx, arg_idx))) voidg_print (const gchar*format, ...) G_GNUC_PRINTF (1, 2); You're not seriously suggesting that DeviceKit-disks usage of g_print instead of printf is actually adding anything useful? The fact is that glib is nothing but a libc wrapper for the low-level usage we're talking about here. And as such, completely unnecessary. I wouldn't have cared if we were discussing ordinary desktop utilities. glib is of course available for them, and it doesn't matter whether you use the printf wrapper or not. But it is not an argument for moving glib to /lib. There is already a printf() in /lib. Use it. Or do you want to take your argument to the kernel as well? Maybe it should use the glib wrappers to avoid bugs and security issues? Right. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit : You're not seriously suggesting that DeviceKit-disks usage of g_print instead of printf is actually adding anything useful? Yeah sure, just look at g_print and not at the other symbols used by devkit-disks-part-id : g_free g_slist_free g_print g_strdup g_printerr g_slist_append g_strdup_printf g_fprintf g_vfprintf g_strchomp g_strjoinv g_slist_length g_malloc0 g_build_filename g_file_get_contents g_utf16_to_utf8 g_strfreev g_slist_nth_data Are you suggesting that such an utility should implement its own linked list structure, and unicode translation functions? Are you aware of the security implications of using snprintf instead of g_strdup_printf? -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
* Josselin Mouette j...@debian.org [090907 12:37]: Are you suggesting that such an utility should implement its own linked list structure, and unicode translation functions? Are you aware of the security implications of using snprintf instead of g_strdup_printf? For the record: Noone sane would replace g_strdup_printf with snprintf, but with asprintf. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Zitat von Josselin Mouette j...@debian.org: Le vendredi 04 septembre 2009 à 19:32 +0200, Hendrik Sattler a écrit : It rather needs to raise the question why simple low-level tools use something like libglib? I’d rather raise the question why each of our simple low-level tools implement its data structures and basic routines in its own fashion, leading to bugs and security issues sometimes, instead of re-using the ones from Glib. You mean useless functions like those only wrap standard functions and add no value except a (build-)dependency to libglib? Very exciting. There may be lots of useful stuff in libglib but some may only be useful as portability wrapper (but some not even for that). Get rid of all of those and I may agree. I fully disagree for using libglib as wrapper around libc. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Josselin Mouette j...@debian.org writes: Le lundi 07 septembre 2009 à 11:48 +0200, Bjørn Mork a écrit : You're not seriously suggesting that DeviceKit-disks usage of g_print instead of printf is actually adding anything useful? Yeah sure, just look at g_print and not at the other symbols used by devkit-disks-part-id : g_free g_slist_free g_print g_strdup g_printerr g_slist_append g_strdup_printf g_fprintf g_vfprintf g_strchomp g_strjoinv g_slist_length g_malloc0 g_build_filename g_file_get_contents g_utf16_to_utf8 g_strfreev g_slist_nth_data Are you suggesting that such an utility should implement its own linked list structure, and unicode translation functions? I'm suggesting that the utility uses lots of g_ prefixed functions while it's obvious that the author never ever evaluated the need for these. I assume that's because the author is used to them always being available. Well, in the context of udev helpers, they are not. Do you really need the g_utf16_to_utf8 unicode translation? You could just as well let udev export the raw utf16 value and leave the conversion up to the users. They may want something different than utf8 anyway. Bjørn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.
Case 1:
char *foo;
if (asprintf(foo, %s equals %i, somestring, someint) 0) {
fprintf(stderr, Failed to allocate memory);
abort();
}
Case 2:
char *foo = g_strdup_printf (%s equals %i, somestring,
someint);
Pick your choice.
--
.''`. Josselin Mouette
: :' :
`. `' “I recommend you to learn English in hope that you in
`- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit : I'm suggesting that the utility uses lots of g_ prefixed functions while it's obvious that the author never ever evaluated the need for these. I assume that's because the author is used to them always being available. Well, in the context of udev helpers, they are not. Starting from the next glib2.0 upload, they will be. End of problem. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
Zitat von Josselin Mouette j...@debian.org: Le lundi 07 septembre 2009 à 15:51 +0200, Bjørn Mork a écrit : I'm suggesting that the utility uses lots of g_ prefixed functions while it's obvious that the author never ever evaluated the need for these. I assume that's because the author is used to them always being available. Well, in the context of udev helpers, they are not. Starting from the next glib2.0 upload, they will be. End of problem. So no trying to convince glib upstream to reduce wrapper bloat? *sigh* HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit : So no trying to convince glib upstream to reduce wrapper bloat? *sigh* What you are calling wrapper bloat is critical for portability of many applications, since it behaves the same on all systems where Glib has been ported. Just because some of them are not useful for writing a udev wrapper is not a good reason for stripping them down from the library. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
On Mon, Sep 07, 2009 at 05:15:44PM +0200, Josselin Mouette wrote: Le lundi 07 septembre 2009 à 16:56 +0200, Hendrik Sattler a écrit : So no trying to convince glib upstream to reduce wrapper bloat? *sigh* What you are calling wrapper bloat is critical for portability of many applications, since it behaves the same on all systems where Glib has been ported. Just because some of them are not useful for writing a udev wrapper is not a good reason for stripping them down from the library. Nobody has advised to strip them down from the library. Just to stop using glib in a small udev binary that only uses glib wrappers. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Le lundi 07 septembre 2009 à 17:32 +0200, Mike Hommey a écrit : Nobody has advised to strip them down from the library. Just to stop using glib in a small udev binary that only uses glib wrappers. And I still believe this advice is wrong. -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée
Re: DeviceKit and /usr
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.
Case 1:
char *foo;
if (asprintf(foo, %s equals %i, somestring, someint) 0) {
fprintf(stderr, Failed to allocate memory);
abort();
}
Case 2:
char *foo = g_strdup_printf (%s equals %i, somestring,
someint);
Pick your choice.
Case 1, please. Either case 2 fails to handle the allocation error, or glib
is doing its own abort. Neither is acceptable.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Re: DeviceKit and /usr
Steve Langasek wrote:
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Le lundi 07 septembre 2009 à 13:40 +0200, Bernhard R. Link a écrit :
For the record: Noone sane would replace g_strdup_printf with snprintf,
but with asprintf.
Case 1:
char *foo;
if (asprintf(foo, %s equals %i, somestring, someint) 0) {
fprintf(stderr, Failed to allocate memory);
abort();
}
Case 2:
char *foo = g_strdup_printf (%s equals %i, somestring,
someint);
Pick your choice.
Case 1, please. Either case 2 fails to handle the allocation error, or glib
is doing its own abort. Neither is acceptable.
and BTW the function seems not documented (I don't find the relevant
manpage).
ciao
cate
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Mon, Sep 07, 2009 at 03:51:54PM +0200, Bjørn Mork wrote: Do you really need the g_utf16_to_utf8 unicode translation? You could just as well let udev export the raw utf16 value and leave the conversion up to the users. They may want something different than utf8 anyway. man 3 iconv -- 1KB // Microsoft corollary to Hanlon's razor: // Never attribute to stupidity what can be // adequately explained by malice. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Mon, Sep 07, 2009 at 04:36:53PM +0200, Josselin Mouette wrote:
Case 1:
char *foo;
if (asprintf(foo, %s equals %i, somestring, someint) 0) {
fprintf(stderr, Failed to allocate memory);
abort();
}
Case 2:
char *foo = g_strdup_printf (%s equals %i, somestring,
someint);
That shows exactly why glib cannot be used for low-level stuff and
daemons: it aborts unconditionally if a memory allocation fails. It's
rather sad, otherwise I love to use glib.
Gabor
--
-
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
-
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 23:29:39 schrieb Steve Langasek: The rationale for this /using glib/ is that devicekit-disks is not an integral part of udev, it's an add-on component that will be installed only on desktop systems. So the size impact to /lib for servers for this component would be negligible; the total size impact of pulling in libglib on the desktop is zero; and the size impact to /lib for desktops is almost certainly also negligible. And what about embedded systems? They start to use those libraries for even the simplest utilities that are also usuable on very small systems. And that's what worries me. If libglib is accepted are core utility in /lib, there will be no end to this :-( (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) *sigh* I agree. Has the world gone mad? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Sep 06, Hendrik Sattler p...@hendrik-sattler.de wrote: And what about embedded systems? They start to use those libraries for even the simplest utilities that are also usuable on very small systems. And that's No, they do not. -- ciao, Marco signature.asc Description: Digital signature
Re: DeviceKit and /usr
Hendrik Sattler p...@hendrik-sattler.de wrote: (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) *sigh* I agree. Has the world gone mad? The desktop world, yes. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: And it is also very unclear to me why this has to be in /lib/udev at all. Because it provides a single point where the desktop hooks into the kernel hotplug event system, instead of having hal redo all the work already done by udev. /That/ much has a sound rationale, even if reading text databases in does not. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DeviceKit and /usr
On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: For your proposal to work, you'd need some kind of replay mechanism, which allows udev to replay the add/remove events when /usr is available the extended ruleset is activated. You mean udevadm trigger? Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: And it is also very unclear to me why this has to be in /lib/udev at all. Because it provides a single point where the desktop hooks into the kernel hotplug event system, instead of having hal redo all the work already done by udev. /That/ much has a sound rationale, even if reading text databases in does not. It's still no rationale at all to use libglib. Even d-bus is not a reason, it is possible to use it without using gobject. If it isn't, fix libdbus first or don't use it. HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Gabor Gombas wrote: On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: For your proposal to work, you'd need some kind of replay mechanism, which allows udev to replay the add/remove events when /usr is available the extended ruleset is activated. You mean udevadm trigger? udevadm trigger afaik only works for coldplug events. It's also a very costly operation. So imho it would require a more elaborate mechanism to only replay a certain set of events, e.g. for rules files which failed (with e.g. a given return code). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Hendrik Sattler wrote: Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: And it is also very unclear to me why this has to be in /lib/udev at all. Because it provides a single point where the desktop hooks into the kernel hotplug event system, instead of having hal redo all the work already done by udev. /That/ much has a sound rationale, even if reading text databases in does not. It's still no rationale at all to use libglib. Even d-bus is not a reason, it is possible to use it without using gobject. If it isn't, fix libdbus first or don't use it. I'm not sure why you bring up libdbus/dbus, but a quick look at dbus' dependencies will show you that it doesn't require libglib. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Hendrik Sattler wrote:
This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL.
and
all current DeviceKit-{power,disks} versions *need* gudev.
And that is usually about the usage of dbus.
DeviceKit-{power,disks} talk to udev directly via lib(g)udev, there is no dbus
involved there.
So I'm still not quite sure yet, what point you are trying to make.
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Re: DeviceKit and /usr
Am Samstag 05 September 2009 11:20:06 schrieb Michael Biebl:
Hendrik Sattler wrote:
Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek:
On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote:
And it is also very unclear to me why this has to be in /lib/udev at
all.
Because it provides a single point where the desktop hooks into the
kernel hotplug event system, instead of having hal redo all the work
already done by udev. /That/ much has a sound rationale, even if
reading text databases in does not.
It's still no rationale at all to use libglib. Even d-bus is not a
reason, it is possible to use it without using gobject. If it isn't, fix
libdbus first or don't use it.
I'm not sure why you bring up libdbus/dbus, but a quick look at dbus'
dependencies will show you that it doesn't require libglib.
This refers to the previously mentioned URL
http://article.gmane.org/gmane.linux.gentoo.devel/62973:
These extras are:
[...]
* gudev: glib/gobject support for libudev
Additionally, further down the thread:
This is the interface almost everything is going to turn to with GNOME
2.28 (via DeviceKit-power and DeviceKit-disks in most cases). By the
time GNOME 2.30 and 3.0 are released, (theoretically) nothing will use
HAL.
and
all current DeviceKit-{power,disks} versions *need* gudev.
And that is usually about the usage of dbus.
HS
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Michael Biebl bi...@debian.org writes: Gabor Gombas wrote: On Fri, Sep 04, 2009 at 06:43:35PM +0200, Michael Biebl wrote: For your proposal to work, you'd need some kind of replay mechanism, which allows udev to replay the add/remove events when /usr is available the extended ruleset is activated. You mean udevadm trigger? udevadm trigger afaik only works for coldplug events. It's also a very costly operation. So imho it would require a more elaborate mechanism to only replay a certain set of events, e.g. for rules files which failed (with e.g. a given return code). Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? It is my understanding that the events get triggered in/before the initramfs and need to be replayed after switching to / already. How is replaying them when entering runlevel 2 any different from that? Or am I wrong there? MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Sat, Sep 05, 2009 at 11:02:51AM +0200, Hendrik Sattler wrote: Am Samstag 05 September 2009 08:18:13 schrieb Steve Langasek: On Fri, Sep 04, 2009 at 09:09:40PM +0200, Bjørn Mork wrote: And it is also very unclear to me why this has to be in /lib/udev at all. Because it provides a single point where the desktop hooks into the kernel hotplug event system, instead of having hal redo all the work already done by udev. /That/ much has a sound rationale, even if reading text databases in does not. It's still no rationale at all to use libglib. Which is not the question I was answering. But if you were just having a rhetorical rant instead of trying to understand, then ok - noted. The rationale for this /using glib/ is that devicekit-disks is not an integral part of udev, it's an add-on component that will be installed only on desktop systems. So the size impact to /lib for servers for this component would be negligible; the total size impact of pulling in libglib on the desktop is zero; and the size impact to /lib for desktops is almost certainly also negligible. The upshot is that we almost certainly will have to move glib to /lib, because there's no way we're going to persuade the devicekit authors that they should avoid using libglib when it's already in /lib on all the systems they care about (so it's not an FHS violation anyway), and I don't think you're going to find anyone willing to maintain a devicekit fork either. (I'll do you one better, though -- system-config-printer upstream wants to install /lib/udev/udev-configure-printer, which pulls in the entire libcups stack. Sigh...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: DeviceKit and /usr
On Sep 05, Goswin von Brederlow goswin-...@web.de wrote: It is my understanding that the events get triggered in/before the initramfs and need to be replayed after switching to / already. How is replaying them when entering runlevel 2 any different from that? The main issue is that the rules which run in the initramfs have almost no side effects (almost no RUN rules, etc). -- ciao, Marco signature.asc Description: Digital signature
Re: DeviceKit and /usr
Marco d'Itri wrote: On Sep 04, Steve Langasek vor...@debian.org wrote: I still can't fathom why someone decided that udev should be responsible for translating PCI IDs and USB IDs into text strings. This smells of crazy. I think that part of the rationale is that eventually HAL will go away replaced by udev and programs like this (e.g. look at the keyboard stuff). I'd like to add here, that devicekit-disks will install udev helpers /lib/udev/devkit-disks-* which are called in /lib/udev/rules.d/95-devkit-disks.rules. devkit-disks-part-id and devkit-disks-probe-ata-smart both link against libraries which are (currently) in /usr/lib, i.e. devkit-disks-part-id links against libglib-2.0 (784K) devkit-disks-probe-ata-smart links against (48K) This will mean, that we will need to install those two libs in /lib. It's not something I'm very keen on to do, but given that almost all of GNOME has migrated to DeviceKit-*, it's not something that imho can be blocked. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Package: devicekit-disks Severity: serious On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote: I'd like to add here, that devicekit-disks will install udev helpers /lib/udev/devkit-disks-* which are called in /lib/udev/rules.d/95-devkit-disks.rules. devkit-disks-part-id and devkit-disks-probe-ata-smart both link against libraries which are (currently) in /usr/lib, i.e. devkit-disks-part-id links against libglib-2.0 (784K) devkit-disks-probe-ata-smart links against (48K) Lets convert that into a bug. What exactly is the use of this tools? This will mean, that we will need to install those two libs in /lib. It's not something I'm very keen on to do, but given that almost all of GNOME has migrated to DeviceKit-*, it's not something that imho can be blocked. Sure it can. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote: I'd like to add here, that devicekit-disks will install udev helpers /lib/udev/devkit-disks-* which are called in /lib/udev/rules.d/95-devkit-disks.rules. devkit-disks-part-id and devkit-disks-probe-ata-smart both link against libraries which are (currently) in /usr/lib, i.e. devkit-disks-part-id links against libglib-2.0 (784K) devkit-disks-probe-ata-smart links against (48K) IMHO this looks more and more like the udev rules has to be split into at least two categories: - a basic set that is used during boot and early system setup. Services in rcS.d are allowed to rely on these rules only, and these rules must not rely on anything outside the root file system. - an extended set that is activated at the beginning of rc[2345].d and contains all the bells and whistles GNOME co. wants. The separation can be done by depending on an environment variable that only gets set using udevadm when transitioning to the default initlevel. Or even better, let's export the current initlevel as an env. variable in udevd, and let rules in the extended set test for that. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Gabor Gombas wrote: IMHO this looks more and more like the udev rules has to be split into at least two categories: - a basic set that is used during boot and early system setup. Services in rcS.d are allowed to rely on these rules only, and these rules must not rely on anything outside the root file system. - an extended set that is activated at the beginning of rc[2345].d and contains all the bells and whistles GNOME co. wants. The separation can be done by depending on an environment variable that only gets set using udevadm when transitioning to the default initlevel. Or even better, let's export the current initlevel as an env. variable in udevd, and let rules in the extended set test for that. The add event for e.g. a disk (partition) will be during early boot. For your proposal to work, you'd need some kind of replay mechanism, which allows udev to replay the add/remove events when /usr is available the extended ruleset is activated. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: DeviceKit and /usr
Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl: devkit-disks-part-id and devkit-disks-probe-ata-smart both link against libraries which are (currently) in /usr/lib, i.e. devkit-disks-part-id links against libglib-2.0 (784K) devkit-disks-probe-ata-smart links against (48K) This will mean, that we will need to install those two libs in /lib. It rather needs to raise the question why simple low-level tools use something like libglib? What does it use from libglib that it couldn't do without? HS -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Hendrik Sattler p...@hendrik-sattler.de writes:
Am Freitag 04 September 2009 16:36:52 schrieb Michael Biebl:
devkit-disks-part-id and devkit-disks-probe-ata-smart both link against
libraries which are (currently) in /usr/lib, i.e.
devkit-disks-part-id links against libglib-2.0 (784K)
devkit-disks-probe-ata-smart links against (48K)
This will mean, that we will need to install those two libs in /lib.
It rather needs to raise the question why simple low-level tools use
something
like libglib?
What does it use from libglib that it couldn't do without?
From the looks of it: Nothing.
This is a code example from
http://cgit.freedesktop.org/DeviceKit/DeviceKit-disks/tree/src/part-id.c :
g_print (DKD_PARTITION=1\n);
g_print (DKD_PARTITION_SCHEME=%s\n,
//part_get_scheme_name (part_table_get_scheme
(partition_table_for_entry)));
part_get_scheme_name (part_table_get_scheme
(partition_table)));
g_print (DKD_PARTITION_NUMBER=%d\n, partition_number);
g_print (DKD_PARTITION_TYPE=%s\n, type != NULL ? type : );
g_print (DKD_PARTITION_SIZE=% G_GINT64_FORMAT \n, size);
g_print (DKD_PARTITION_LABEL=%s\n, label != NULL ? label :
);
g_print (DKD_PARTITION_UUID=%s\n, uuid != NULL ? uuid : );
g_print (DKD_PARTITION_FLAGS=%s\n, flags_combined);
g_free (type);
g_free (label);
g_free (uuid);
g_strfreev (flags);
g_free (flags_combined);
} else {
g_print (DKD_PARTITION_TABLE=1\n);
g_print (DKD_PARTITION_TABLE_SCHEME=%s\n,
part_get_scheme_name (part_table_get_scheme
(partition_table)));
}
Looks like someone is unable to spell printf.
And it is also very unclear to me why this has to be in /lib/udev at
all. It seems to add nothing but redundant information and bugs. Maybe
the DDs could start asking upstream a few questions before blindly
accepting things like that? That might save them a few bug reports
later on.
Bjørn
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
