Good news on the S/390 parted front. ---------- Forwarded Message ---------- Subject: Re: D-I Etch Beta2 release status & timeline Date: Thursday 19 January 2006 16:11 From: Adam Thornton On Jan 19, 2006, at 5:17 AM, Frans Pop wrote: > ISSUES > ====== > - S/390 support is very unlikely for Beta2; basically nothing has > happened > yet since Beta1 to fix the parted support; this may yet change > though This is still true but not nearly as true as it was this time last week. Please excuse the large Cc: list on this note, but I want to make sure that everyone who *ought* to be in the loop on this one actually is. Current status of parted: Back in 2004, Leland Lucius actually wrote a lot of the s390 parted support. This has been in the Debian patch set for a while, but was de-applied by Otavio Salvador, because it changes, outside of s390 code, the requirement for 512-byte sectors. This appears to be an architectural limitation with parted. There's no way to get non-512-byte sectors without touching non-s390 code. That said, though, if we do it right, upstream (as represented by Leslie Polzer) doesn't have any objection to removing the 512-byte- sector limitation, especially since there are now devices appearing that have larger sector sizes (RAID arrays and such), which parted needs to support, so it really *isn't* a System/390-specific problem anymore. In the last two days I've gotten in touch with Leland, Otavio, and Leslie, and it looks like we are finally getting some sort of overview of who has done what, and perhaps getting a consensus on where to go next. As I see it, s390 support is technically pretty close (this is all due to Leland, not me, by the way), but implementing it in a way acceptable to Otavio and Leslie may be a bit trickier; not a whole lot, though, given that upstream doesn't have any fundamental problem with generically supporting large sectors. More fundamentally, the problem with parted support has been that there hasn't been a lot of communication between the people responsible for it in different contexts; I'm hoping that simply by involving Leland, Otavio, and Leslie, we can find a mutually-acceptable solution without having to rewrite a whole lot of the code that's already been done. Adam -------------------------------------------------------
Attachment:
pgphrdrLIF18S.pgp
Description: PGP signature