Date: Wed, 18 Jun 2003 02:44:24 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [Ux2bs_Archive] No. 155 ************************************************** Tuesday 17 June 2003 Number 155 ************************************************** Subjects for today 1 Re: baseline .. some thoughts : Henry Sobotka 2 Re: Update on EMX symlink compatibility : Marty" 3 Re: Update on EMX symlink compatibility : Marty" 4 Re: baseline .. some thoughts : Stefan.Neis at t-online.de 5 Re: Update on EMX symlink compatibility : Sebastian Wittmeier (ShadoW)" 6 Re: Update on EMX symlink compatibility : Ken Ames 7 Re: Update on EMX symlink compatibility : mamodeo at stny.rr.com 8 Re: Update on EMX symlink compatibility : Sebastian Wittmeier (ShadoW)" 9 Update on EMX symlink compatibility : Andrew Belov" 10 Re: Update on EMX symlink compatibility : Andrew Belov" 11 rsyncd : T.Sikora" 12 Re: Update on EMX symlink compatibility : Marty" 13 Reminder : T.Sikora" 14 Re: Update on EMX symlink compatibility : Sebastian Wittmeier (ShadoW)" 15 Re: Update on EMX symlink compatibility : Andrew Belov" 16 Re: baseline .. some thoughts : Andreas Buening 17 Re: Update on EMX symlink compatibility : Andrew Belov" **= Email 1 ==========================** Date: Wed, 18 Jun 2003 01:24:15 -0400 From: Henry Sobotka Subject: Re: baseline .. some thoughts Andreas Buening wrote: > > The problem is that we need one (or more) maintainers who know how and > where to apply the patches. Everybody can add a function foo() and add > a header sys/foo.h. But not everybody can know > - how to write the code consistent with other libc modules, e.g. to > enable or disable features by macros like _POSIX_SOURCE, > - where to add the source files to preserve some order for the source > files, > - which Makefiles/config files have to be changed, > - how to keep the emx online docs uptodate to the available functions, > - whether the new function has to be registered in some .def file > - and so on Think of the mailing list through which all patches must go as the maintainer(s). Since the patches have to be diffs against the CVS repository, it's immediately obvious where the proposed changes will go, and anyone who feels they belong elsewhere, or are inconsistent with other modules, or inefficient or unnecessary or could be handled in other ways can start screaming and the issue gets thrashed out among the people on the list. A stream of code filtered through ten or twenty or more pairs of eyes will likely end up better than one processed by a troika or whatever of official maintainers, who might build up a backlog because of time constraints, other interests etc., or simply wander off, or put patches on the backburner because they don't have a clue whether or not the code is okay, or be driven by some petty grudge etc. etc. Also, CVS is a two-way street: if a patch gets blessed and checked in, and some time later someone raises serious issues or problems with the patch, it can easily be backed out. Documentation could be a requirement, i.e. if you add a new function, or change its parameters, return values, behavior etc., you have to supply a patch for the docs (or beg or bribe someone to do it for you). h~ _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 2 ==========================** Date: Wed, 18 Jun 2003 08:52:20 -0400 (EDT) From: "Marty" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 16:18:51 +0300 (MSK), Andrew Belov wrote: > If the symlink interface hasn't gone "stable" yet, I propose to simplify > the EA format by (1) removing the EAT_ASCII word, and (2) dropping the > null terminator. This should finally make it 100% compatible with Linux. > Sorry for inconvenience. I can easily make my code tolerant of the Linux format, but I'd prefer to not go against the WPS standards for EAs if I can avoid it. Veit Kannegieser reported that he had some WPS extensions which interpret EAs that choked on my format before I put the EAT_ASCII and length words in there. Is it possible to submit a change to the Linux driver? I'd gladly do that patch, but I can't test it because I don't have Linux installed. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 3 ==========================** Date: Wed, 18 Jun 2003 09:40:28 -0400 (EDT) From: "Marty" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 15:33:42 +0200 (CEST), Sebastian Wittmeier (ShadoW) wrote: > Will be solved, when the symlink extension is built in ring 0. I think we'd want the Linux driver to be changed in either case. It's creating EAs on your HPFS partitions that don't conform to WPS standards. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 4 ==========================** Date: Wed, 18 Jun 2003 12:14:40 +0200 (CEST) From: Stefan.Neis at t-online.de Subject: Re: baseline .. some thoughts Henry Sobotka schrieb: Hi, > Think of the mailing list through which all > patches must go as the maintainer(s). Since the > patches have to be diffs against the CVS > repository, > Also, CVS is a two-way street: if a patch gets > blessed and checked in, and some time later > someone raises serious issues or problems with the > patch, it can easily be backed out. Actually, I've been thinking about it the other way round: someone just commits his changes to CVS and CVS automagically generates such a mail. And if the changes are considered to be bad, they get backed out again, if somebody thinks they need some refinement, everything to start from is already there... And if you're particularly unsure about a certain change, you can still make a patch and send it for discussion first. I've seen that model working nicely, but I admit it could also be a problem . But for starting it seems to be the easiest... Regards, Stefan _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 5 ==========================** Date: Wed, 18 Jun 2003 15:33:42 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 08:52:20 -0400 (EDT), Marty wrote: >I can easily make my code tolerant of the Linux format, but I'd prefer to not go >against the WPS standards for EAs if I can avoid it. Veit Kannegieser reported that >he had some WPS extensions which interpret EAs that choked on my format before I put >the EAT_ASCII and length words in there. Will be solved, when the symlink extension is built in ring 0. Sebastian _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 6 ==========================** Date: Wed, 18 Jun 2003 15:52:31 -0400 From: Ken Ames Subject: Re: Update on EMX symlink compatibility with IBM and Microsoft as the original designers/implementers of hpfs, it should be linux that bows to EA proper storage. If linux needs to have it's hpfs driver changed then a well written and documented patch should be accepted by the linux community without much trouble. Ken Andrew Belov wrote: >On Wed, 18 Jun 2003 15:55:24 +0000, mamodeo at stny.rr.com wrote: > > > >>>Patched Linux will write raw EAs, being able to read raw EAs and >>>EAT_ASCII EMX will create EAT_ASCII EAs, being able to read >>>EAT_ASCII and raw EAs >>> >>> >>I actually envisioned making the Linux patch read both, but write the >>EAT_ASCII form. So the raw entry tolerance would be a backward >>compatibility feature, but wouldn't be needed on new "clean" systems. >> >> > >As I've said previously: don't break too much in Linux. :-) 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. > > >_______________________________________________ >UX2BS mailing list >UX2BS at os2ports.com >http://os2ports.com/mailman/listinfo/ux2bs > > > _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 7 ==========================** Date: Wed, 18 Jun 2003 15:55:24 +0000 From: mamodeo at stny.rr.com Subject: Re: Update on EMX symlink compatibility > There is no technical difficulty to patch Linux, but in this case we'll > end up with a dual-standard behavior that is really off-the-wall: > > Patched Linux will write raw EAs, being able to read raw EAs and > EAT_ASCII EMX will create EAT_ASCII EAs, being able to read > EAT_ASCII and raw EAs I actually envisioned making the Linux patch read both, but write the EAT_ASCII form. So the raw entry tolerance would be a backward compatibility feature, but wouldn't be needed on new "clean" systems. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 8 ==========================** Date: Wed, 18 Jun 2003 16:09:45 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 18:04:25 +0300 (MSK), Andrew Belov wrote: >The EA-capable Linux HPFS driver has a track record since about 1998. It was in >use already on 2.0 and 2.2 before joining the 2.4 kernel officially, so I believe we'd >better break something here rather than there. Why break? You could patch the Linux hpfs driver that it accepts both formats. So existing systems are happy, and only every OS/2 user with the new symlink library should also update his Linux system. Sebastian _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 9 ==========================** Date: Wed, 18 Jun 2003 16:18:51 +0300 (MSK) From: "Andrew Belov" Subject: Update on EMX symlink compatibility Just tried the new release, now it's definitely more compatible with Linux, thanks Marty! There still remains an important issue - shame I haven't noticed it previously. Our symlink library employs EAT_ASCII prefixes and ASCIIZ filenames, so "ln -s gcc-2.95.3 gcc" results in the following EA data: {FD FF 0B 00} "gcc-2.95.3" {00} [15 bytes] However, the Linux HPFS solution assigns the SYMLINK EA with "raw" EA data, not even null-terminated: "gcc-2.95.3" [10 bytes] So we can barely read Linux EAs - probably getting some random garbage in the tail, as no '\0' terminator is present: [E:\usr\bin]ls -l|grep ">" lrw-rw---a 0 Jun 14 19:02 c++ -> /local/bin/arjdisp lrw-rw---a 0 Jun 14 19:02 cc -> /local/bin/arjdisp lrw-rw---a 0 Jun 14 19:02 g++ -> gcc-2.95.3\x01 lrw-rw---a 0 Jun 14 19:02 gcc -> 2.95.395.3\x01 lrw-rw---a 0 Jun 14 19:02 i386-slackware-linux-gcc -> 2.95.3\x1E lrw-rw---a 0 Jun 14 18:50 perl -> 5.6.1\x01\x1E lrw-rw---a 0 Jun 14 18:50 pstruct -> 5.6.1\x01\x1E ...and Linux fails to understand the EAT_ASCII prefix - it treats it as a part of filename. If the symlink interface hasn't gone "stable" yet, I propose to simplify the EA format by (1) removing the EAT_ASCII word, and (2) dropping the null terminator. This should finally make it 100% compatible with Linux. Sorry for inconvenience. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 10 ==========================** Date: Wed, 18 Jun 2003 18:04:25 +0300 (MSK) From: "Andrew Belov" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 08:52:20 -0400 (EDT), Marty wrote: >> If the symlink interface hasn't gone "stable" yet, I propose to simplify >> the EA format by (1) removing the EAT_ASCII word, and (2) dropping the >> null terminator. This should finally make it 100% compatible with Linux. >> Sorry for inconvenience. > >I can easily make my code tolerant of the Linux format, but I'd prefer to not go >against the WPS standards for EAs if I can avoid it. Veit Kannegieser reported that >he had some WPS extensions which interpret EAs that choked on my format before I put >the EAT_ASCII and length words in there. As far as I know, the EA description word is not a WPS standard; it traces back to the age of SAA and OS/2 v 1.2. I'm aware of some modern widespread programs (e.g. the FED/2 editor) that do not adhere to these guidelines. My vision is that we are playing clear even if we choose to omit the description word - so the EA would most likely fall into the "reserved" category (for system/app use depending on high bit). Next, the EA name classifies it as an application data ("SYMLINK" as opposed to system-like ".SYMLINK") meaning it's of some proprietary use - third-party software should not expect some structured format, based on the above facts. >Is it possible to submit a change to the Linux driver? I'd gladly do that patch, >but I can't test it because I don't have Linux installed. The EA-capable Linux HPFS driver has a track record since about 1998. It was in use already on 2.0 and 2.2 before joining the 2.4 kernel officially, so I believe we'd better break something here rather than there. If it is imperative that we follow the OS/2 standards, then I would propose a configuration hack: an environment variable, or EMXOPT suboption to permit creating Linux-style symlink EAs. Upon resolving the EA, its data should be examined for zero terminator (preferred over the EAT_ASCII header for NLS issues). _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 11 ==========================** Date: Wed, 18 Jun 2003 18:07:39 -0400 From: "T.Sikora" Subject: rsyncd Rysncd has proven unreliable on OS/2, both builds. Causes the server to lockup under heavy load. Was John ever successful in rebuilding it? Has anyone successfully ported it here? -- Ted _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 12 ==========================** Date: Wed, 18 Jun 2003 19:04:03 -0400 (EDT) From: "Marty" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 22:34:09 +0300 (MSK), Andrew Belov wrote: > On Wed, 18 Jun 2003 15:55:24 +0000, mamodeo at stny.rr.com wrote: > > >> Patched Linux will write raw EAs, being able to read raw EAs and > >> EAT_ASCII EMX will create EAT_ASCII EAs, being able to read > >> EAT_ASCII and raw EAs > > > >I actually envisioned making the Linux patch read both, but write the > >EAT_ASCII form. So the raw entry tolerance would be a backward > >compatibility feature, but wouldn't be needed on new "clean" systems. > > As I've said previously: don't break too much in Linux. :-) Well.. if I'm not too much of a putz, I won't break anything. On second thought, maybe someone else should do it. ;-) > 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. My main concern is the OS/2 side of the functionality. If I can make the OS/2 side look and act the way more native OS/2 things do, I'd prefer that solution. If we can get Linux HPFS compatibility at the same time, all the better. But I wouldn't want to go against OS/2 native conventions to accommodate Linux. I'd rather make Linux conform to the OS/2 conventions when accessing an OS/2 filesystem. 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 don't want this to stagnate into religious arguments. I want this coded and working. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 13 ==========================** Date: Wed, 18 Jun 2003 19:07:08 -0400 From: "T.Sikora" Subject: Reminder Just a reminder that the UX2BS is on 2 rsync servers. Fast and reliable too. rsync os2ports.com:: rsync dumbdog.org:: The UX2BS portal: http://ux2bs.powerusersbbs.net I'm working on getting wget running smoothly for the bootstrap. When working we will have an additional server, powerusersbbs.net. -- Ted _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 14 ==========================** Date: Wed, 18 Jun 2003 19:24:00 +0200 (CEST) From: "Sebastian Wittmeier (ShadoW)" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 15:55:24 +0000, mamodeo at stny.rr.com wrote: >> Patched Linux will write raw EAs, being able to read raw EAs and >> EAT_ASCII EMX will create EAT_ASCII EAs, being able to read >> EAT_ASCII and raw EAs > >I actually envisioned making the Linux patch read both, but write the me too Sebastian _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 15 ==========================** Date: Wed, 18 Jun 2003 19:43:14 +0300 (MSK) From: "Andrew Belov" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 16:09:45 +0200 (CEST), Sebastian Wittmeier (ShadoW) wrote: >>The EA-capable Linux HPFS driver has a track record since about 1998. It was in >>use already on 2.0 and 2.2 before joining the 2.4 kernel officially, so I believe we'd >>better break something here rather than there. > >Why break? You could patch the Linux hpfs driver that it accepts both >formats. >So existing systems are happy, and only every OS/2 user with the new >symlink library >should also update his Linux system. There is no technical difficulty to patch Linux, but in this case we'll end up with a dual-standard behavior that is really off-the-wall: Patched Linux will write raw EAs, being able to read raw EAs and EAT_ASCII EMX will create EAT_ASCII EAs, being able to read EAT_ASCII and raw EAs Reminds me of some app from the 16-bit OS/2 days which was switching between MVMT and raw EA storage in unusual sense. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 16 ==========================** Date: Wed, 18 Jun 2003 19:48:22 +0200 From: Andreas Buening Subject: Re: baseline .. some thoughts Stefan.Neis at t-online.de wrote: [snip] > Actually, I've been thinking about it the other way > round: someone just commits his changes to CVS and > CVS automagically generates such a mail. And if the changes are > considered to be bad, they get backed > out again, if somebody thinks they need some refinement, everything to > start from is already there... A patch doesn't only consist of the diffs. There should also be some ChangeLog info, who did what and why. And one sentence about how the code is working. Therefore I'd prefer a normal mailing list where patches can be discussed. If there are no objections then the patches can be applied. [snip] Bye, Andreas _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs **= Email 17 ==========================** Date: Wed, 18 Jun 2003 22:34:09 +0300 (MSK) From: "Andrew Belov" Subject: Re: Update on EMX symlink compatibility On Wed, 18 Jun 2003 15:55:24 +0000, mamodeo at stny.rr.com wrote: >> Patched Linux will write raw EAs, being able to read raw EAs and >> EAT_ASCII EMX will create EAT_ASCII EAs, being able to read >> EAT_ASCII and raw EAs > >I actually envisioned making the Linux patch read both, but write the >EAT_ASCII form. So the raw entry tolerance would be a backward >compatibility feature, but wouldn't be needed on new "clean" systems. As I've said previously: don't break too much in Linux. :-) 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. _______________________________________________ UX2BS mailing list UX2BS at os2ports.com http://os2ports.com/mailman/listinfo/ux2bs