linux-kernel - Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

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: <20070422135835.037e323c@the-village.bc.nu>
Date:	Sun, 22 Apr 2007 13:58:35 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Tilman Schmidt <tilman@...p.cc>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	kkeil@...e.de, i4ldeveloper@...tserv.isdn4linux.de,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] Remove "obsolete" label from ISDN4Linux (v3)

> >> If it isn't obsolete then fix the code to use the newer APIs
> 
> Why should that be a precondition for removing the incorrect
> "obsolete" label?

Because if we remove the obsolete label the users are going to be
suprised when it goes away entirely with && BROKEN or && !HOTPLUG or
similar.

> >> to end up && BROKEN let alone Obsolete.
> 
> That can't happen. Any change that breaks isdn4linux before its
> replacement is ready would constitute a regression.
> We've been there once, remember?

Want to be on that. There is nobody maintaining it. That isn't a
sustainable situation so it will break.

> I beg to differ. Existence of a working replacement is exactly
> the criterion we arrived at when discussing the meaning of the
> term "obsolete". So lack of a working replacement *is* an
> argument for concluding that something is not obsolete.

Ok then it should be marked "BROKEN" instead.

> - The authors of certain in-kernel API changes seem to have
>   neglected the isdn4linux subsystem in their work.

For simile changes they have kept it going (eg the tty changes), but the
code is too big and too messy for that to happen for all things. Thus
it will eventually break

> - These are two independent problems. Blocking the correction of
>   one of them because the other one still exists doesn't help,
>   but only risks deadlock.

No risk of deadlock. It'll progress to && BROKEN which will either cause
sufficient pain for someone to get off their arse and fix it, for enough
of a vendors users to get the vendor to do the work or for someone who
cares to pay a third party to do the work.

Alan
-
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/