IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* fix typo (hs vs. hbb)
* set id->{version,usage,type} when all tests pass
* be paranoid and don't use hs->version when "hs" source buffer was
possibly modified by next volume_id_get_buffer() call.
Signed-off-by: Karel Zak <kzak@redhat.com>
On Tue, Dec 2, 2008 at 21:07, Matthias Schwarzott <zzam@gentoo.org> wrote:
> It seems that the rules related to capi devices are not correct:
>
> KERNEL=="capi", NAME="capi20", SYMLINK+="isdn/capi20"
> KERNEL=="capi*", NAME="capi/%n"
>
> Changing the second rule to match only on KERNEL=="capi[0-9]*" is reported to
> make it work.
> So I can only guess that the problem is the second rule overwriting the NAME
> set by the first one.
On Thu, Nov 20, 2008 at 14:17, Karel Zak <kzak@redhat.com> wrote:
> I see the patch (volume_id_probe_filesystem()) and a few things come
> to mind:
>
> - shouldn't be the relevant parts (label, uuid, version, ...) of
> the "struct volume_id" zeroized when you found a signature and
> before you call the next probing function?
>
> - it seems as overkill to use two for()s and probe two times for all
> filesystems. What about to store the first result and re-use it?
>
> - .. or at least never use the second for() when the fist for() found
> nothing ;-)
The klibc implementation of getopt_long() behaves slightly different
from the glibc one - in particular, it treats the change of the option
string argument between invocations as start of parsing a different
command line, and resets its state. However, the udevadm code
expected getopt_long() invocations in subcommands to continue parsing
the rest of command line after initial options has been parsed at the
top level; with klibc this broke, causing all udevadm subcommands to
stop recognizing their options.
Instead of relying on the glibc behavior, reset the getopt_long()
state properly before invoking the subcommand handler: move argv to
point to the subcommand name, decrease argc appropriately, and set
optind = 0. This also fixes a minor bug visible with glibc - without
setting optind = 0 all getopt_long() calls in subcommand handlers were
behaving as if "+" was specified as the first character of the option
string (which disables option reordering), because that state was set
by the first getopt_long() call at the top level, and was not reset
when parsing subcommand options.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
