linux-kernel - Re: tools support for non-512 byte sector sizes

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: <20080729185002.GD24924@parisc-linux.org>
Date:	Tue, 29 Jul 2008 12:50:02 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	Ric Wheeler <rwheeler@...hat.com>, linux-scsi@...r.kernel.org,
	linux-ide@...r.kernel.org, Jim Meyering <jim@...ering.net>,
	linux-kernel@...r.kernel.org, Martin Petersen <mkp@....net>,
	Jeff Garzik <jeff@...zik.org>,
	Matt Domsch <Matt_Domsch@...l.com>
Subject: Re: tools support for non-512 byte sector sizes

On Tue, Jul 29, 2008 at 01:44:38PM -0500, James Bottomley wrote:
> On Tue, 2008-07-29 at 12:42 -0600, Matthew Wilcox wrote:
> > On Tue, Jul 29, 2008 at 01:37:25PM -0500, James Bottomley wrote:
> > > scsi_debug does exactly the same thing, so it reports anything you tell
> > > it (Martin Petersen actually added this so he could test with 4k
> > > sectors).
> > > 
> > > The problem, which ata_ram also suffers, is that the tools we most need
> > > to test are the ones for manipulating non volatile characteristics (like
> > > partition tables).  We'd really like the disk contents to survive reboot
> > > for this ...
> > 
> > Ummm... _reboot_, or _module unload/reload_?  I could certainly include
> > an option to populate the ramdisc from a file.  Is the ioctl to re-read
> > the partition table not enough?
> 
> reboot ... we'd like to take the tools through shutdown restart testing
> to make sure they're all working ... of course, then there's the
> bios ...

It's not up to us to fix the BIOS.

Since the vast majority of users use a distro, and the vast majority of
distros use a fully modular kernel, wouldn't initialising the contents
of ata-ram from the initrd/initramfs solve the problem?

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/