linux-kernel - Re: [PATCH 1/3] ide: add "ignore

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] [day] [month] [year] [list]

Date:	Wed, 27 May 2009 13:41:52 +0200
From:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Frans Pop <elendil@...net.nl>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/3] ide: add "ignore_hpa" module parameter

On Wednesday 27 May 2009 12:38:57 Alan Cox wrote:
> > All information was there (kernel logs).
> > 
> > Moreover the default in libata is to not remove HPA settings.
> > 
> > I don't recommend parsing kernels logs in search of such information but
> > you're are stretching the reality too far to match with your arguments.
> 
> So you disagree that sysfs is needed and propose an alternative that you
> say you don't recommend (and which doesn't solve the block problem).

This is not what I said (if this is a straw man attempt, please don't do it).

> I used to work for a distro, and telling Bill Nottingham that the
> reliable long term way for Fedora to obtain some interface data was by
> grepping dmesg wouldn't have gone down well.

Knowing the severity of accidentally removing data from HPA (which you
described yourself in the other mail) and also not being able to access
valid data from HPA (bug #13365) I would simply use in the installer
the alternative [*] (that I *don't* recommend as the long-term solution)
and then start working on adding proper sysyfs kernel interfaces (that
I *don't* consider not needed) and proper installer support.

[*] it would of course require passing "libata.ignore_hpa=1" to kernel
    during installation time

This would result in much less hassle for users, much less support costs
for distribution and having proper in-kernel / installer support faster
than doing it the non-pragmatic way (since we would save a lot of time on
handling bug-reports and discussions like this one).
--
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/