Re: Future of ext2 support in the Hurd?
On Sun, Aug 12, 2007 at 08:13:36PM -0700, Roland McGrath wrote: > Indeed some people do use the Hurd and they all do rely on the EXT2_OS_HURD > format support in e2fsprogs. It's the intended plan to migrate away from > EXT2_OS_HURD format and use a strict subset of the ext2 format features > used natively by Linux ext2fs (in theory eventually that whole set). The > Hurd-specific data now stored in inode fields in EXT2_OS_HURD format would > instead be stored in ext2 xattr format. The extent of cooperation then > required between ext2 format authorities and Hurd developers is assigning > an EXT2_XATTR_INDEX_* number to correspond to the "gnu." prefix. The > conventions for formats and semantics of attributes with this prefix will > be maintained by the GNU Project. Good plan. :-) Especially if you end up using a larger inode, and supporting the EA-in-inode feature, I think you will find a huge speed boost to files that use translators. Out of curiosity, do you view this as something which will be a common case, or an usual one (i.e., files using passive translators which are specified in the filesystem)? Even if you don't, if a large number of files are always using the same translator, there will probably be some significant disk space savings with storing that information in an extended attribute. > If it is important to you and you would like to state a quasi-formal > schedule to deprecate EXT2_OS_HURD format (not instantaneously), we can > work with that. We'd hope for a decent interval of backward compatibility > support in e2fsck. (The Hurd code will probably continue to support the > old format indefinitely.) Hurd developers can make a small push to get our > ext2fs code supporting the xattr format encoding of Hurd-specific metadata. > If you're feeling especially charitable, you could provide format > conversion support in e2fsprogs. We don't need to give an explicit schedule, no. I don't want to force this to happen fast if the Hurd doesn't have volunteers lined up to do the work. As I mentioned earlier, the union is annoying, but it's hardly a major obstacle to code maintainability. I am certainly open to including format conversion in e2fprogs, if someone sends me patches. I doubt I will have the bandwidth to write the patches myself in the near future; I have many other todo's on my plate at the moment. Working with you to assign a number for the name index is something that I can help you do. In fact, I think 7 is available; why don't I reserve it and then get back to you once it's been formally merged. One thing that *would* be useful if you could provide some text (that would go into the ext2/3/4 wiki) describe exactly what subset of the ext2 filesystem is currently supported by the Hurd, and what the rough roadmap you have for supporting additional features. For example, do you currently support sparse_superblocks, etc. BTW, it may be that you would want to supply a different /etc/mke2fs.conf file in the e2fsprogs patches so that filesystems created by mke2fs don't include features that might potentially give the Hurd ext2fs driver heartburn --- I get the distinct feeling that it hasn't supported many of the more recent innovations that are in the Linux implementation. Regards, - Ted ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Future of ext2 support in the Hurd?
On Mon, Aug 13, 2007 at 02:02:11AM +0200, Marcus Brinkmann wrote: > In fact, I just searched for your name, and it pops up in the network > stack, but not in the ext2fs translator (the above files are copyright > Remy Card and Linus Torvald). I only did a quick look, but I recognized some Linux code in balloc.c, at least. The code I think was probably written originally by Stephen Tweedie. We weren't very careful about maintaining authorship attribution until after we moved to the BitKeeper (and later git) for source code management. I probably only have minimal kernel ownership in terms of lines of code, with the exception being the directory indexing changes and extended attribute code, which got reworked by me before they were merged into mainline. Most of my code ownership from a copyright standpoint is in e2fsprogs. > This matches my best understanding of the issues involved. Beyond > that, I can not say anything that applies particularly to the Hurd or > its RPC interfaces. It will be especially interesting since some RPC interfaces (mediated by libc) will be used by GPLv2 userspace programs (such as e2fsck :-), and some of those exact same interfaces will be used by Hurd translators, and it will be interesting to see the legal interpretations/contortions necessary to justify making some of these distinctions. :-) > That is an important question, but for now the Hurd is GPLv2, for > exactly that reason. There are other significant parts of the Hurd > taken from Linux, so we can't do a complete switch at this time. To > make a partial switch, we would have to address the issues you raised. > > Beside the FSF' position, your position (and Remy Cards', Linus > Torvalds' etc) matters as well, of course. Well, the general consensus of the ext2/3/4 developers at this point is to keep things at GPLv2. My personal opinion matches with Linus which is while I think that "Tivoization" in many cases will be a bad choice from a marketing point of view (see how well Circuit City's Divx venture fared), but it's not something that should be legislated via the licenses. If someone wants to use ext3 inside a locked down device, that's fine with me, as long as I can get any improvements to the source code back; I don't feel that it's worth it for the license the mandate that I MUST be able to replace the running binaries inside any embedded device. So I don't see the Linux kernel going GPLv3 at any time in the near future, and probably not ever. Regards, - Ted ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: Future of ext2 support in the Hurd?
On Mon, Aug 13, 2007 at 01:27:02AM +0200, Marcus Brinkmann wrote: > We have no intention to drop support for it. In fact, we are very > happy with it. How much are we a burden for you? If it helps, we can > probably arrange it so that a volunteer cooperates with you if work is > involved in keeping the support active. As long as there are people using it, we'll keep supporting it. If we could drop support for HURD-specific inode fields, it would clean up a somewhat annoying union in the filesystem data structures, but that's a minor point. Something that *would* be good would be to have a volunteer periodically check to make sure that the tip of the "maint" and "master" branches of e2fsprogs builds and passes the regression test suite on Hurd. This may be somewhat happenning with the GNU/Hurd Debian project, since the latest Debian version of e2fsprogs is 1.40.2, and I assume (although I don't know for sure) that the Debian GNU/Hurd port is tracking Debian unstable, so if there were anything embarassing, I would have gotten a complaint. Still, it would be good to explicitly run the regression test suite to make sure things are working correctly --- and if not, to send patches. This is just to make sure e2fsprogs is working fine for the Hurd, of course; it's not like I would drop support if you can't find a volunteer to do this, but at the moment we do no testing on Hurd and there is no guarantees that a particular new release will work on the Hurd because none of the active developers have a Hurd box. Regards, - Ted ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
