Date: Thu, 25 Mar 2004 00:04:08 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 324 ************************************************** Wednesday 24 March 2004 Number 324 ************************************************** Subjects for today 1 Re: Undefined symbol _chroot : Stefan Neis 2 Re: Undefined symbol _chroot : John Poltorak 3 Re: Reviewing old code : Dave and Natalie" 4 Re: Reviewing old code : John Poltorak 5 Re: *.h,v files : Steven Levine" 6 Re: *.h,v files : John Poltorak 7 Re: Undefined symbol _chroot : Dave Saville" 8 Re: *BSD headers : John Merryweather Cooper 9 Re: checking for pnmcut... missing : Michael Zolk 10 FreeBSD : John Poltorak 11 Re: Undefined symbol _chroot : Sebastian Wittmeier" 12 File v4.08 : John Poltorak 13 Re: FreeBSD : John Merryweather Cooper 14 Re: FreeBSD : John Merryweather Cooper 15 Re: File v4.08 : Steve Wendt 16 Re: *BSD headers : Steve Wendt 17 Re: *.h,v files : Andrew MacIntyre 18 Re: *.h,v files : Steven Levine" 19 Re: *BSD headers : John Merryweather Cooper 20 Re: Reviewing old code : Dave and Natalie" 21 Re: Undefined symbol _chroot : Holger Veit 22 /vfs? : Henry Sobotka 23 Re: /vfs? : Holger Veit 24 Re: FreeBSD : John Poltorak 25 Posix/2 headers : John Poltorak 26 Re: File v4.08 : John Poltorak 27 Re: Building gcc 3.2.2 : Knut Stange Osmundsen 28 Re: Posix/2 headers : Knut Stange Osmundsen **= Email 1 ==========================** Date: Tue, 23 Mar 2004 13:51:31 +0100 (CET) From: Stefan Neis Subject: Re: Undefined symbol _chroot On Tue, 23 Mar 2004, John Poltorak wrote: > I didn't understand your post... I'm trying to build RSYNC. Does the > build pick up options from the conf-file? Apparently, it does... If it builds on Windows, there sure is a way to build it without requiring chroot ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 2 ==========================** Date: Tue, 23 Mar 2004 15:38:32 +0000 From: John Poltorak Subject: Re: Undefined symbol _chroot On Tue, Mar 23, 2004 at 01:51:31PM +0100, Stefan Neis wrote: > On Tue, 23 Mar 2004, John Poltorak wrote: > > > I didn't understand your post... I'm trying to build RSYNC. Does the > > build pick up options from the conf-file? > > Apparently, it does... > If it builds on Windows, there sure is a way to build it without requiring > chroot ... I've looked in configure and Makefile and don't see any indication that the build process reads rsyncd.conf and there isn't one supplied. I haven't found any docs saying that its build can be controlled by entries in the conf file, so I would be surprised if this works... > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 3 ==========================** Date: Tue, 23 Mar 2004 08:07:51 -0800 From: "Dave and Natalie" Subject: Re: Reviewing old code On Tue, 23 Mar 2004 11:18:57 +0000, John Poltorak wrote: > >Looking through some old OS/2 ports by KUR, I wonder if some patches are >required any longer because of improvements in Autoconf... > >Can anyone tell me if this is still necessary:- ? > > >#ifdef OS2 >#include >#define chdir(p) _chdir2(p) >#endif It's sopposed to help support drive letters so I think it should be kept Dave **= Email 4 ==========================** Date: Tue, 23 Mar 2004 16:22:29 +0000 From: John Poltorak Subject: Re: Reviewing old code On Tue, Mar 23, 2004 at 08:07:51AM -0800, Dave and Natalie wrote: > On Tue, 23 Mar 2004 11:18:57 +0000, John Poltorak wrote: > > > > >Looking through some old OS/2 ports by KUR, I wonder if some patches are > >required any longer because of improvements in Autoconf... > > > >Can anyone tell me if this is still necessary:- ? > > > > > >#ifdef OS2 > >#include > >#define chdir(p) _chdir2(p) > >#endif > > It's sopposed to help support drive letters so I think it should be kept If it's generic to OS/2, then shouldn't there be some way to incorporate it into the build system at a higher level than adding specific code into particular applications? I wouldn't know how to do that, BTW, but if it is system specific I thought such functionality could be abstracted to a generic layer, although I have no idea about any available mechanism. > Dave -- John **= Email 5 ==========================** Date: Tue, 23 Mar 2004 08:42:06 -0800 From: "Steven Levine" Subject: Re: *.h,v files In <20040323121302.J40261 at warpix.org>, on 03/23/04 at 12:13 PM, John Poltorak said: >> Yes, there is, but it requires installing CVS learning to use it enough to >> create a local repository and do a checkout. Let me know if you want >> instructions. >Is there any way to simply install them? Which them? The files in the CVS respository or the checked out source code usable by your compiler? >If I was installing FreeBSD, I wouldn't need to go through a procedure >involving CVS, would I? Maybe yes. Maybe no. It depends on what files you start with. You chose to start with the content of the CVS respository. HTH, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 6 ==========================** Date: Tue, 23 Mar 2004 16:59:14 +0000 From: John Poltorak Subject: Re: *.h,v files On Tue, Mar 23, 2004 at 08:42:06AM -0800, Steven Levine wrote: > >If I was installing FreeBSD, I wouldn't need to go through a procedure > >involving CVS, would I? > > Maybe yes. Maybe no. It depends on what files you start with. You chose > to start with the content of the CVS respository. The CVS repository was the only thing I could find which contained FreeBSD's headers - the layout appears very different to OpenBSD. I would start else if I could.. For example, if I have the FreeBSD installation CD, presumably the headers will be on there and get copied to /usr/include on installation... I don't know the mechanism for this or the source location - maybe there is a shell script which I could run to install them somewhere under OS/2... > HTH, > > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 > www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- -- John **= Email 7 ==========================** Date: Tue, 23 Mar 2004 17:51:19 +0000 (GMT) From: "Dave Saville" Subject: Re: Undefined symbol _chroot On Tue, 23 Mar 2004 11:24:29 +0000, John Poltorak wrote: >On Tue, Mar 23, 2004 at 12:14:39PM +0100, Stefan Neis wrote: >> On Tue, 23 Mar 2004, John Poltorak wrote: >> >> > > add #ifndef __EMX__ / #endif around the call. >> > >> > Is there an alternative? Maybe including a dummy _chroot somewhere which >> > does nothing... >> >> Not really. chroot("/Some_directory") means that any file name given later >> on as e.g. "/local_dir/filename" actually refers to >> "/Some_directory/local_dir/filename", so if you add a chroot doing >> nothing, that's bound to cause trouble to later calls involving file >> names. > >I don't know anything about chroot, but is it impossible to incorporate >its functionality into OS/2? Is Windows any different? I'd expect existing >code to make similar checks around any use of chroot... The application is >available for Windows. The idea behind chroot is that anyone accessing the system through an app using it cannot cd anywhere other than under the chroot tree - Rsync, ftp, web servers etc. HTH -- Regards Dave Saville **= Email 8 ==========================** Date: Tue, 23 Mar 2004 11:34:31 -0800 From: John Merryweather Cooper Subject: Re: *BSD headers In response to your questions John Poltorak wrote: > On Mon, Mar 22, 2004 at 05:40:52PM -0800, John Merryweather Cooper wrote: > >>Well, that's not the installed directory structure. The CVS repository >>reflects the source directory structure. > > > How do you set about grabbing the installed directory structure? I suppose > you need to install it... Would that be possible? > > > >>See attached for the include directory tree off my FreeBSD 4.9-STABLE >>machine. >> >>jmc >> >>John Poltorak wrote: >> >> >>>On Sun, Mar 21, 2004 at 05:23:44PM -0800, John Merryweather Cooper wrote: >>> >>> >>>>For access to the CVS by web, try >>>> >>>>http://www.freebsd.org/cgi/cvsweb.cgi/src/include/ >>>> >>>>The full hierarchy is available. By hooking up with CVS in the usual >>>>way, you can fetch all of them. >>> >>> >>>The directory structure appears strange to me... >>> >>>There are quite a lot of headers missing under src/include, but many are >>>to be found under src/sys/sys, src/sys/netinet etc although I can't locate >>>anything related to what we usually have as include/machine. Any idea >>>where that can be found, or what it is derived from? >>> >>>I've also found that it is easier for me to grab headers using RSYNC >>>rather than CVS. >>> >>> >>> >>> >>> >>>>jmc >>>> >>>>John Poltorak wrote: >>>> >>>> >>>>>Can anyone tell me where to download the standard *BSD headers? >>>>> >>>>>I thought they might be here:- >>>>> >>>>>ftp://ftp.openbsd.org/pub/OpenBSD/src/include/ >>>>> >>>>>but there are only a few... >>>>> >>>>>Where are the rest? >>>>> >>>>> >>>> >>>> >>> >>> > > Some of these look familiar, but many don't... > > >>/usr/include > > >>/usr/include/arpa > > >>/usr/include/cam > > > ? CAM is an API layer for manipulating SCSI devices (although FreeBSD now has an ATAPICAM emulation also) > > >>/usr/include/dev > > >>/usr/include/fs > > > ? Virtual file system stuff. > > >>/usr/include/g++ > > > c++ ? Correct. FreeBSD currently uses a hacked GCC, although a hacked version of Intel's ICC has recently been made to build a working kernel. > > >>/usr/include/isc > > > ? Got me there, but I think it's related to file systems. > > >>/usr/include/isofs > > > ? Part of the file systems interface. There are several abstraction layers in FreeBSD to make it easier to support files systems as diverse as MS-DOS to NFS. > > >>/usr/include/libmilter > > > sendmail? Correct, although the API interface also supports compatible alternatives like postfix. > > > >>/usr/include/machine > > >>/usr/include/net > > >>/usr/include/netatalk > > > ? Apple networking API interface ("AppleTalk"). > > >>/usr/include/netatm > > > ? Mostly related to ATM communications (high bandwidth, sattelite stuff most useful to big servers). > > >>/usr/include/netgraph > > > ? This API interface allows modules to be written to interface and do processing on IP in the kernel. > > >>/usr/include/netinet > > >>/usr/include/netinet6 > > > ip v6 ? Correct. > > >>/usr/include/netipx > > > netware? Correct. > > >>/usr/include/netkey > > > ? Support API's used by IPSEC, etc. > > >>/usr/include/netnatm > > > ? More ATM stuff. > > >>/usr/include/netncp > > > ? More Novell API stuff. > > >>/usr/include/netns > > > ? An old Xerox protocol that isn't quite working yet. > > >>/usr/include/netsmb > > > samba? Correct. > > > >>/usr/include/nfs > > > >>/usr/include/ntfs > > > ? Windows NT File System interface. > > >>/usr/include/nwfs > > > netware? Correct. > > >>/usr/include/objc > > >>/usr/include/openssl > > > openssl? Correct. > > >>/usr/include/pccard > > > ? Interface to PC Cards for laptops. > > >>/usr/include/posix4 > > > ? Posix 4 standards-compliant API (FreeBSD is BIG on standards). > > >>/usr/include/protocols > > >>/usr/include/rpc > > > ? Portmapper stuff mainly used "under the hood" for NFS files system. > > >>/usr/include/readline > > > readline? Correct. > > >>/usr/include/rpcsvc > > >>/usr/include/security > > > ? Crypto API's. > > >>/usr/include/sys > > >>/usr/include/ufs > > > ? Unix File System--the native file system for FreeBSD (-CURRENT uses UFS2) > > >>/usr/include/vm > > > ? Virtual Machine API (kernel memory management, etc.) > > >>/usr/include/crypto > > > openssl? Yes. > > >>/usr/include/netipsec > > > ? IPSEC for enhanced (read "working") wireless security. > > > > **= Email 9 ==========================** Date: Tue, 23 Mar 2004 22:02:47 +0100 From: Michael Zolk Subject: Re: checking for pnmcut... missing On Fri, Mar 19, 2004 at 10:23:10AM +0000, John Poltorak wrote: > > > Whilst building GROFF, configure checks for pnmcut but doesn't find it. > > Anyone know what it is or where to find it? It's part of netpbm. It cuts a rectangular area from an image file and outputs this to stdout. Michael **= Email 10 ==========================** Date: Tue, 23 Mar 2004 20:54:34 +0000 From: John Poltorak Subject: FreeBSD If anyone on this list is familiar with FreeBSD could you say whereabouts on the CD you could expect to find the headers which get installed into /usr/include? -- John **= Email 11 ==========================** Date: Tue, 23 Mar 2004 22:08:30 +0100 (CET) From: "Sebastian Wittmeier" Subject: Re: Undefined symbol _chroot On Tue, 23 Mar 2004 17:51:19 +0000 (GMT), Dave Saville wrote: >The idea behind chroot is that anyone accessing the system through an >app using it cannot cd anywhere other than under the chroot tree - >Rsync, ftp, web servers etc. Perhaps it is enough to change the behaviour of libc calls so that Unix applications can successfully be ported. OS/2 API calls are more difficult (doable with Security/2???) Sebastian **= Email 12 ==========================** Date: Tue, 23 Mar 2004 21:41:09 +0000 From: John Poltorak Subject: File v4.08 v4.08 of the handy FILE utility has just been released and is obtainable from:- ftp://ftp.astron.com/pub/file/file-4.08.tar.gz I'm pleased to say that 'build file' was all that it took to build and install the file using UX2BS. If anyone has access to a Unix system which includes FILE, could you say where it and the MAGIC support file are installed? -- John **= Email 13 ==========================** Date: Tue, 23 Mar 2004 13:09:00 -0800 From: John Merryweather Cooper Subject: Re: FreeBSD On the first CD. It's a little harder than just picking a tarball as /stand/sysinstall usually handles the dirty work of decompressing the various tarballs into the write places--and there are well over a dozen just for the base system. Of course, I could just ZIP /usr/include and send it off to you if you wish . . . jmc John Poltorak wrote: > If anyone on this list is familiar with FreeBSD could you say whereabouts > on the CD you could expect to find the headers which get installed into > /usr/include? > > > **= Email 14 ==========================** Date: Tue, 23 Mar 2004 13:09:00 -0800 From: John Merryweather Cooper Subject: Re: FreeBSD On the first CD. It's a little harder than just picking a tarball as /stand/sysinstall usually handles the dirty work of decompressing the various tarballs into the write places--and there are well over a dozen just for the base system. Of course, I could just ZIP /usr/include and send it off to you if you wish . . . jmc John Poltorak wrote: > If anyone on this list is familiar with FreeBSD could you say whereabouts > on the CD you could expect to find the headers which get installed into > /usr/include? > > > **= Email 15 ==========================** Date: Tue, 23 Mar 2004 16:14:48 -0800 (PST) From: Steve Wendt Subject: Re: File v4.08 On Tue, 23 Mar 2004, John Poltorak wrote: > If anyone has access to a Unix system which includes FILE, could you say > where it and the MAGIC support file are installed? ~>rpm -ql file /usr/bin/file /usr/share/magic /usr/share/magic.mgc /usr/share/magic.mime /usr/share/magic.mime.mgc /usr/share/man/man1/file.1.gz /usr/share/man/man5/magic.5.gz /usr/share/misc/magic **= Email 16 ==========================** Date: Tue, 23 Mar 2004 16:12:23 -0800 (PST) From: Steve Wendt Subject: Re: *BSD headers On Tue, 23 Mar 2004, John Merryweather Cooper wrote: > >>/usr/include/isc > > ? > > Got me there, but I think it's related to file systems. ISC is probably the Internet Software Consortium, the group that provides BIND and DHCP. **= Email 17 ==========================** Date: Wed, 24 Mar 2004 08:53:27 +1100 (EST) From: Andrew MacIntyre Subject: Re: *.h,v files On Tue, 23 Mar 2004, John Poltorak wrote: > I would start else if I could.. For example, if I have the FreeBSD > installation CD, presumably the headers will be on there and get copied to > /usr/include on installation... I don't know the mechanism for this or > the source location - maybe there is a shell script which I could run to > install them somewhere under OS/2... You will have better luck with CD #2 of the 4-CD sets, which is a "live" CD (primarily intended for recovery operations etc, as its not quite a live CD in the genre of Knoppix). -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 18 ==========================** Date: Tue, 23 Mar 2004 19:19:14 -0800 From: "Steven Levine" Subject: Re: *.h,v files In <20040323165914.S40261 at warpix.org>, on 03/23/04 at 04:59 PM, John Poltorak said: >The CVS repository was the only thing I could find which contained >FreeBSD's headers - the layout appears very different to OpenBSD. That may be true. I'm not really keeping up with this stuff all the well at the moment. >installation CD, presumably the headers will be on there and get copied >to /usr/include on installation... I'm sure a FreeBSD install with development tools would install the /usr/include and so on, but it appears you don't want to do that. After reading a bit a the FreeBSD website, I get the impression that they intend for folks to use CVS to keep up to date on the source. See: http://www.freebsd.org/support.html#cvs If it were me, I would just use anon cvs to pull the /usr/include part of the source tree rather than creating a local respository. Instructions for anon cvs are at: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html and there's a one page getting started guide at: http://www.scoug.com/os24u/2003/scoug305.mrkia.html Once you get logged in: cvs co usr/src/include will get you the current trunk version of all the include files. HTH, Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.41 #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.webbnet.info irc.fyrelizard.org #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 19 ==========================** Date: Tue, 23 Mar 2004 21:32:12 -0800 (PST) From: John Merryweather Cooper Subject: Re: *BSD headers Yes, I should have thought of that, it is the internal bind. jmc --- Steve Wendt wrote: > On Tue, 23 Mar 2004, John Merryweather Cooper wrote: > > > >>/usr/include/isc > > > ? > > > > Got me there, but I think it's related to file > systems. > > ISC is probably the Internet Software Consortium, > the group that provides > BIND and DHCP. > **= Email 20 ==========================** Date: Tue, 23 Mar 2004 22:16:00 -0800 From: "Dave and Natalie" Subject: Re: Reviewing old code On Tue, 23 Mar 2004 16:22:29 +0000, John Poltorak wrote: >On Tue, Mar 23, 2004 at 08:07:51AM -0800, Dave and Natalie wrote: >> On Tue, 23 Mar 2004 11:18:57 +0000, John Poltorak wrote: >> >> > >> >Looking through some old OS/2 ports by KUR, I wonder if some patches are >> >required any longer because of improvements in Autoconf... >> > >> >Can anyone tell me if this is still necessary:- ? >> > >> > >> >#ifdef OS2 >> >#include >> >#define chdir(p) _chdir2(p) >> >#endif >> >> It's sopposed to help support drive letters so I think it should be kept > >If it's generic to OS/2, then shouldn't there be some way to incorporate >it into the build system at a higher level than adding specific code into >particular applications? I wouldn't know how to do that, BTW, but if it is >system specific I thought such functionality could be abstracted to a >generic layer, although I have no idea about any available mechanism. > You can abstract these functions to a generic layer but which way do you abstract them? For some functions chdir is the better choice and for other functions chdir2 is a better choice. Of course if we got rid of drive letters and just had everything on one partition this would be immaterial. Think of telling TAR to extract a file on C: to D: why it is running on X:. It needs to use chdir2 to set the directory on C: and D: while maintaining its working directory on X: (so upon exit it is still on X:). I don't totally understand this. I do understand that OS/2 is not Unix and if you want to port programs and have them interact with the rest of the OS/2 system you have to make some changes to the code. Dave **= Email 21 ==========================** Date: Wed, 24 Mar 2004 09:02:51 +0100 From: Holger Veit Subject: Re: Undefined symbol _chroot On Tue, Mar 23, 2004 at 05:51:19PM +0000, Dave Saville wrote: > On Tue, 23 Mar 2004 11:24:29 +0000, John Poltorak wrote: > > >On Tue, Mar 23, 2004 at 12:14:39PM +0100, Stefan Neis wrote: > >> On Tue, 23 Mar 2004, John Poltorak wrote: > >> > >> > > add #ifndef __EMX__ / #endif around the call. > >> > > >> > Is there an alternative? Maybe including a dummy _chroot somewhere which > >> > does nothing... > >> > >> Not really. chroot("/Some_directory") means that any file name given later > >> on as e.g. "/local_dir/filename" actually refers to > >> "/Some_directory/local_dir/filename", so if you add a chroot doing > >> nothing, that's bound to cause trouble to later calls involving file > >> names. > > > >I don't know anything about chroot, but is it impossible to incorporate > >its functionality into OS/2? Is Windows any different? I'd expect existing > >code to make similar checks around any use of chroot... The application is > >available for Windows. > > The idea behind chroot is that anyone accessing the system through an > app using it cannot cd anywhere other than under the chroot tree - > Rsync, ftp, web servers etc. As long as the application and its offspring uses the runtime library that provides chroot(), it can be enforced: once the app has done chroot("/xxx"), the runtime library takes care that file accesses with drive letters are prohibited, and absolute paths are redirected to point below "/xxx". The tricky part of it is the handling of DLLs. Holger **= Email 22 ==========================** Date: Wed, 24 Mar 2004 03:57:35 -0500 From: Henry Sobotka Subject: /vfs? Could the perennial conflict between root- and drive-letter-based file systems be resolved once and for all by creating a root-based (installable) virtual file system? Like TVFS in having to be linked to real bytes on a tangible harddrive to be useful. Unlike it in knowing nothing about drive letters, other than automatically creating a /dev/hd[..] tree with the partitions and other devices on the system. Accessed from a command prompt, it would amount to a filesystem shell for running software that assumes a root-based FS. It could come with a FHS tree by default, and on first launch scan the system and create links, e.g. put sh, grep, awk, perl etc. if found in ../bin etc., and keep a record of locations for future reference. Ideally, it would be able to accommodate any variety of root-based systems, from strict FHS to completely customized by each simply being a known (stored) configuration of the filesystem (different sets of connections to locations on the hardware). To what extent is something like this feasible as an IFS? h~ -- Free software, free minds. **= Email 23 ==========================** Date: Wed, 24 Mar 2004 10:45:00 +0100 From: Holger Veit Subject: Re: /vfs? On Wed, Mar 24, 2004 at 03:57:35AM -0500, Henry Sobotka wrote: > Could the perennial conflict between root- and drive-letter-based file > systems be resolved once and for all by creating a root-based > (installable) virtual file system? Like TVFS in having to be linked to > real bytes on a tangible harddrive to be useful. Unlike it in knowing > nothing about drive letters, other than automatically creating a > /dev/hd[..] tree with the partitions and other devices on the system. > Accessed from a command prompt, it would amount to a filesystem shell > for running software that assumes a root-based FS. It could come with a > FHS tree by default, and on first launch scan the system and create > links, e.g. put sh, grep, awk, perl etc. if found in ../bin etc., and > keep a record of locations for future reference. Ideally, it would be > able to accommodate any variety of root-based systems, from strict FHS > to completely customized by each simply being a known (stored) > configuration of the filesystem (different sets of connections to > locations on the hardware). To what extent is something like this > feasible as an IFS? It is two layers too low. An IFS is a subsystem that is tied to a device which provides a contiguous storage space. A device in this context is either a single hard disk partition or a physical device that somehow otherwise provides access to storage space. Examples for the latter are pseudo devices that provide NFS access, or the TVFS logic itself. TVFS itself works be a user level redirect; you need a user process there which keeps all the real open files that other processes open on the TVFS drive and processes all file I/O on behalf of its TVFS.IFS. The next layer to consider might be a special kind of DMD driver. A DMD driver keeps score of drive letters, and associates them with the real disk partitions, and takes care that each letter has an associated IFS that dispatches the various file I/O requests. A specialized DMD driver might just grab all information about partitions, like the common OS2DASD.DMD but doesn't export a single letter for each managed partition. Rather it would combine all of them to a single letter. Difficulty is IIRC that a DMD doesn't know anything about file systems - that's what it directs to the corresponding IFS for the partition. Idea might be a combination of a DMD and an IFS that provides a single root partition. The DMD would then manage the partitions and redirect everything to a single "root"-IFS which would then multiplex requests to subordinate IFSs for each maintained partition. IMHO, such an approach has never been attempted before (without an assisting user level process). It might well be that the DMD/IFS APIs prevent such a knack as they were not constructed for this. Another alternative intercepts at the API level. Known is that it works for runtime libraries - they could for instance change certain characteristic file paths to point to different paths, e.g. could redirect any 'Q:/XFree86' to 'C:/usr/X11R6' (independently of the letter 'Q:', if any at all). You could easily implement symbolic links at this level. Problem is that this magic fails when there is code that doesn't use this runtime library, and thus also doesn't know symbolic links or transparent redirects. Thus, it has to be the DosOpen itself that should translate 'Q:/XFree86' to 'C:/usr/X11R6', before the actual file is opened (the layers below then just see a plain file open of some file named differently). The only viable way to do this is through the ISS CALLGATE16/CALLGATE32 APIs (the highlevel SEC* functions are just callbacks to monitor the access of files which don't allow anything to be changed). While CALLGATE32 is really simply to use, CALLGATE16 directly leads into the 16/32 thunking hell of the kernel. Without it, though, about half of the old \OS2 programs which are still 16 bit will no longer work correctly. Holger **= Email 24 ==========================** Date: Wed, 24 Mar 2004 09:55:41 +0000 From: John Poltorak Subject: Re: FreeBSD On Tue, Mar 23, 2004 at 01:09:00PM -0800, John Merryweather Cooper wrote: > On the first CD. It's a little harder than just picking a tarball as > /stand/sysinstall usually handles the dirty work of decompressing the > various tarballs into the write places--and there are well over a dozen > just for the base system. Of course, I could just ZIP /usr/include and > send it off to you if you wish . . . Thanks, but I have located the directory I want on CD-2 of the FreeBSD distro. It is available here as an ISO image:- ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/5.2.1/5.2.1-RELEASE-i386-disc2iso This can be mounted using mntisofs. > jmc > > John Poltorak wrote: > > If anyone on this list is familiar with FreeBSD could you say whereabouts > > on the CD you could expect to find the headers which get installed into > > /usr/include? > > > > > > > > -- John **= Email 25 ==========================** Date: Wed, 24 Mar 2004 10:48:07 +0000 From: John Poltorak Subject: Posix/2 headers In the absence of any activity on the Posix/2 list, I hope it is OK to discuss Posix/2 here, since I hope most people who are still interested, will be on this list... AIUI Posix/2 is based on *BSD, and having just got hold of /usr/include from FreeBSD for comparison purposes, I note the absence of the directories asm & i386 and wonder where these originated and if they are necessary. It looks like a lot of work has gone into Posix/2 and it would be nice to see it become the basis of a new libc for OS/2. So, if FreeBSD is to be a guide for our libc, is it possible to get it completely inline? I notice that all the headers under asm are just redirected to i386 and wondered which programs actually required asm or i386... -- John **= Email 26 ==========================** Date: Wed, 24 Mar 2004 11:56:09 +0000 From: John Poltorak Subject: Re: File v4.08 On Tue, Mar 23, 2004 at 04:14:48PM -0800, Steve Wendt wrote: > On Tue, 23 Mar 2004, John Poltorak wrote: > > > If anyone has access to a Unix system which includes FILE, could you say > > where it and the MAGIC support file are installed? > > ~>rpm -ql file > /usr/bin/file > /usr/share/magic > /usr/share/magic.mgc > /usr/share/magic.mime > /usr/share/magic.mime.mgc > /usr/share/man/man1/file.1.gz > /usr/share/man/man5/magic.5.gz > /usr/share/misc/magic Is the last file just a link to /usr/share/magic ? Here is what I have when building with --prefix=/usr :- /usr/bin/file.exe /usr/share/file/magic /usr/share/file/magic.mgc /usr/share/file/magic.mime /usr/share/file/magic.mime.mgc /usr/man/man1/file.1 /usr/man/man3/libmagic.3 /usr/man/man4/magic.4 I guess I need to change the location of the man directory to /usr/share/man and then it should be OK. I wonder if there is a target for Make which would allow it to be built as a package rather than getting installed... -- John **= Email 27 ==========================** Date: Wed, 24 Mar 2004 13:23:58 +0100 From: Knut Stange Osmundsen Subject: Re: Building gcc 3.2.2 Adrian Gschwend wrote: > On Tue, 23 Mar 2004 00:17:17 +1100 (EST), Andrew MacIntyre wrote: > > >>As the dominant distribution, in userbase size, FreeBSD is probably the >>best one to use as a reference for the headers & C library - being the >>next most common porting target after the Linux distro du jour... From a >>userland perspective, there's not a lot of difference between 4.x and 5.x, >>despite the changes in the kernel and library internals. > > > yes that's my point of view as well. Also I am working with BSD 4.x and > 5.x and I didn't run in any problems yet compiling stuff. Considering all the stuff which build on FreeBSD 5.2 (the entire system it self and probably most if not all of the ports), so chances are pretty low that a 5.x release contains really bad headers. For LIBC I've always tried to use sources and headers from the latest 5.x release under the assumption that 5.x is more conforming to late standards (like C99). I've two ways of getting the stuff, checking out the release in CVS and zipping up /usr/include on an installed system. As you might have noticed the headers I've updated or added to LIBC includes a note about what it was based on and hints about the changes. Kind Regards, knut **= Email 28 ==========================** Date: Wed, 24 Mar 2004 13:38:14 +0100 From: Knut Stange Osmundsen Subject: Re: Posix/2 headers John Poltorak wrote: > In the absence of any activity on the Posix/2 list, I hope it is OK > to discuss Posix/2 here, since I hope most people who are still > interested, will be on this list... > > AIUI Posix/2 is based on *BSD, and having just got hold of > /usr/include from FreeBSD for comparison purposes, I note the absence > of the directories asm & i386 and wonder where these originated and > if they are necessary. It looks like a lot of work has gone into > Posix/2 and it would be nice to see it become the basis of a new libc > for OS/2. So, if FreeBSD is to be a guide for our libc, is it > possible to get it completely inline? I notice that all the headers > under asm are just redirected to i386 and wondered which programs > actually required asm or i386... The directory perhaps corresponding to i386 and asm is called machine on FreeBSD. Any BSD dependencies on these directories should go away if the code is reprogrammed to a more current version of BSD (preferably have 'Free' in front of that 'BSD' IMHO). The LIBC should be able to shop code from both BSD and LGPL worlds, perhaps prefering BSD if having multiple options. (The best place of getting a GNU extension is usually to GLIBC, not *BSD.) Thus the basic layout of headers should be BSD like, while LGPL stuff would have to be made fit in somehow. Kind Regards, knut