linux-kernel - Re: [PATCH] ide: update Kconfig text to mark as deprecated

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]

Date:	Fri, 30 Oct 2009 00:32:32 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Robert Hancock <hancockrwd@...il.com>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH] ide: update Kconfig text to mark as deprecated

> > 1) Add a way for the ATA layer to create compat device
> >   nodes so that people can change over to use the ATA
> >   layer for their devices without any fstab et al. changes.
> >
> >   These compat device nodes do not have to be so featureful
> >   that they support hdparm or smartd or anything like that,
> >   but they need to work well enough to mount filesystems, and
> >   mount swap partitions, and interact with device management
> >   systems like udev as if they were real IDE devices.
> 
> I'm not really sure if this is worthwhile.. is having to update fstab
> really so onerous as to be worth the trouble? You'd presumably have to
> enable the creation of the compat device nodes somehow (enabling them
> by default seems like it would cause a lot of confusion), so it's not
> like you wouldn't need any config changes that way, either.

Not worth the pain or the code complexity. Almost no system today hard
codes the identifiers. For those that do you can use a udev rule to make
symlinks.

> > 2) The two or so remaining devices which have IDE support but
> >   don't have an ATA layer driver need porting.
> 
> Has anyone gone through and made a list of these? pmac seems like the
> most obvious one..

Pmac is probably the only one that matters. It basically needs an
alternate set of DMA sg drivers for the MAC DMA, the rest is very
"normal". The other is SGIIOC4 which I doubt anyone cares about.

There are a few other things that I think could do with addressing
particularly better IRQ unmasking for both polled PIO (embedded devices)
and interrupt driven PIO on relatively sane hardware would be helpful
particularly in the embedded world.

IDE will self correct in time anyway - new hardware doesn't work with it,
newer embedded devices are also moving away from compact flash, so it'll
die of its own accord.

As such while things like pmac support in libata will be nice I don't
think there is any need to go around obsoleting it or pressuring people
to move stacks.

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/