lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <806dafc20701251240t70335055l74c47ecdd09d1944@mail.gmail.com>
Date:	Thu, 25 Jan 2007 15:40:06 -0500
From:	xiphmont@...h.org
To:	"Greg KH" <greg@...ah.com>
Cc:	"Takashi Iwai" <tiwai@...e.de>, "Pierre Ossman" <drzeus@...eus.cx>,
	fedora-desktop-list@...hat.com, alsa-devel@...a-project.org,
	jrb@...hat.com, linux-kernel@...r.kernel.org, mclasen@...hat.com,
	"Lennart Poettering" <lennart@...ttering.net>, perex@...e.cz
Subject: Re: [Alsa-devel] [PATCH] alsa: correct nonsensical sysfs device symlinks

> Basically, new distros can disable that option if their userspace can
> handle the new structure of sysfs with the symlinks.  Users of older
> distros with newer kernels can enable the option and (hopefully) not
> break anything.

I would like to register a general objection to a change of this size
'hoping to not break anything' in a stable release update (seeing as
how something did break), especially as how no one here who was
maintaining the userspace was apparently even aware it was coming.

> So far, it's been working with this being the first
> regression reported.

Had it worked properly, it still would have been a regression.  This
seems similar to the ALSA copout ("maintaining a kernel ABI is hard!
We require you have a userspace officially approved by us matching
your kernel, and that is your API.") except that in this case, the
userspace maintainence doesn't seem to be as tightly coupled (is hald
the only thing that broke?)

> > (Well, it's incomplete like my original patch was in that it only
> > changed the device symlinks for controlX and pcmX; the other entries
> > still had device entries pointing at card*).
>
> So what does running with this patch make sysfs look like?

A union of old and new, with old taking precedence over new when they
conflict.  That is, the [eg] pcmCXdXx entries look like old sysfs, but
the new entries for cardX etc are there too.  All device symlinks
point to /sys/device/pciXXXX:XX/XXXX:XX:XX.x entries as before.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ