Date: Thu, 19 Jun 2003 02:44:26 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 156 ************************************************** Wednesday 18 June 2003 Number 156 ************************************************** Subjects for today 1 Re: Update on EMX symlink compatibility : Andrew Belov" **= Email 1 ==========================** Date: Thu, 19 Jun 2003 13:16:02 +0300 (MSK) From: "Andrew Belov" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 19:04:03 -0400 (EDT), Marty wrote: >> For consistency >> reasons, we may have to redesign the EA storage format for other values >> which Linux stores in EAs as well (-rwxrwxrwx, devices, etc.) Then the >> patch has to be pushed into 2.4 (which is now mature - "handle with care") >> and traced into 2.5. Personally I've never submitted a kernel patch for >> Linux, therefore I'm taking a conservative position. > >Ok, so if we were going to be consistent about such a change, several other areas >would have to change too, making the possible exposure to errors bigger. Precisely. In fact, it was not so long ago (around 2.4.20) when we could finally see both HPFS and JFS in Linux working flawlessly. After Mikulas Patocka has submitted his HPFS driver for the 2.3 branch, it was mishandled by maintainers long after 2.4 got on the track. >With all that in mind, you (Andrew) had mentioned that this is really an >application-specific EA and doesn't need to conform to any standards. But Veit had >a specific and useful-sounding OS/2 application that relied on these standards. I'd >rather look "normal" to OS/2 native applications than a Linux filesystem driver. > >We can have the best of both worlds, though. I can release unofficial patches to >the Linux HPFS kernel driver, which can be built into a loadable module, and people >can use it at their own risk if they want the compatibility. If we find that it >works well, we can later submit the changes to the Linux kernel team. Does that >sound good? Is there someone out there willing to build and test the module for me >after I make the changes (since I don't run Linux here)? I'll take a look on the HPFS driver after I move my OS/2 + Slackware setup back to HPFS (it's on JFS for now - but with symlink library, HPFS would offer more usability than JFS, which still displays the ongoing discordance between Steve Best and the OS/2 team). Still I would like the "EMXOPT hack" to be considered, that is, letting the user choose whether he/she wants EMX to establish the EAT_ASCII EA headers or not. I understand that in the long-term (when/if this code gets moved to a kernel-mode driver, and HPFS is rendered useless on a 300G HDD), it might only impose additional complexity. Nevertheless, if you get to implementing this hack, just note the EA identification approach I've described earlier: check for zero terminator, not EAT_ASCII. This is to prevent any NLS issues - I've got a little weary "unfixing" PJ28318 due to a similar reason :-) _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs