From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Thu, 21 Oct 93 23:13:09 EDT Subject: Linux-Development Digest #179 Linux-Development Digest #179, Volume #1 Thu, 21 Oct 93 23:13:09 EDT Contents: Re: PATH_MAX and malloc.h (Jay Lawrence) Re: SCSI-ADA-2742T (Scott Ferris) Re: Andrew File System (Charles T Wilson -- Personal Account) Re: UNIX trademark now X/Open (Chris Flatters) Re: Andrew File System (sjh@unixuser.chi.il.us) Re: ugly name for core dumps (core.imagename) -> patch for "img.core" (Drew Eckhardt) meta-fs device idea (Francois-Rene Rideau) 1.72MB floppies (Francois-Rene Rideau) developping an OO environment over Linux ? (Francois-Rene Rideau) Re: Andrew File System (Court Demas) ---------------------------------------------------------------------------- From: jjlawren@undergrad.math.uwaterloo.ca (Jay Lawrence) Subject: Re: PATH_MAX and malloc.h Date: Thu, 21 Oct 1993 20:41:31 GMT In article <2a5gmb$bkv@klaava.helsinki.fi>, Linus Torvalds wrote: >In article , >>Then I also go NET2debugged, and noticed that there was 1.21BETA, went >>to make kernel but it called for malloc.h, which aswell, I don't have. > >The ALPHA-pl13h kernel should also fix one long-standing problem where >the machine hangs when swapping heavily under some circumstances. It >seems the buffer cache simply ran out of buffers and everything waited >for more buffers to magically appear. As it happened, this miracle >never does occur, so everything just grinds to a halt. That is exactly what I am trying to rectify. I would get buffer allocation errors periodically. I guess I am using the OS fairly heavily. > Linus Among other things, THANKS! Jay ------------------------------ From: sferris@sydney (Scott Ferris) Subject: Re: SCSI-ADA-2742T Date: 21 Oct 1993 21:54:16 GMT Ralf.Schroers@gmd.de wrote: : Hi! : I have an ADAPTEC 2742T SCSI-Controller. I saw in HOW-TO-SCSI that this : Controller is not supported by Linux. My question is: is there any : possibility are hack known to use Linux mith this Controller. : Many thanks. The 274x series is basically a single chip controller, and is not backwards compatible with the 174x. I'm still working on getting documentation from Adaptec. Their Literature department is very poor at locating documents, though they are free if they ever do find them. I've heard on the net that Adaptec has some new policy about releasing programming information, but haven't run into anything yet myself. Anyone interested in a driver for the 274x series (or the AIC-7770 chip in general) can email me at the address below. I'll be setting up a mailing list for info on a Linux driver, since I doubt there will be enough interest to justify using the SCSI mailing list til there's soemthing resembling a working driver. I believe the AIC-7770 ASIC was designed to reduce the chip count on the controller by putting everything on one chip, rather than a radical new interface method, so I'm hoping it will work mostly like the Enhanced mode of the 174x, though without docs I can't confirm that. If all else fails, I'll try reverse-engineering the DOS or OS/2 drivers Adaptec ships, though I'm going to wait a few weeks and see if I can get some docs first, as I'm really not in the mood for assembly right now. Any development or testing assistance would be greatly appreciated. I've only got 1 scsi drive, and I can't really afford to have a bad driver overwrite some of the more critical info on it. Hopefully someone out there has a system with data they're willing to lose on alpha tests. : ralf.schroers@gmd.de -- Scott Ferris, sferris@macalstr.edu LaserMaster Inc, Macalester College, and points in between. ------------------------------ From: ctwilson@rock.concert.net (Charles T Wilson -- Personal Account) Subject: Re: Andrew File System Date: 21 Oct 1993 23:40:13 GMT In article , Jim Howard wrote: >Does a port or complete rewrite of the Andrew file system (AFS) exist >for Linux? > >Is such a project possible, if it does not already exist? AFS is the intellectual property of Transarc corp. A clone *might* be possible, but lacking source, it might be hard to write without being plagaristic; it's pretty sophisticated. >Is it something that people would want if it does not already exist? Hard to say....AFS is mainly used to be a replacement for NFS with added security and other file ownership features by my employer. Its virtual file systems (volumes) are a pretty nice feature. They can exist anywhere on a disk. The nearest equivalent I can think of is the old CMS virtual disk; AFS volumes, however, are static until deassigned, whereas CMS volumes, I think, are more session-oriented. -- /-----------------------------------------------------------------------\ | Tom Wilson | "I can't complain, but sometimes | | ctwilson@rock.concert.net | I still do." | | | -Joe Walsh | ------------------------------ From: cflatter@nrao.edu (Chris Flatters) Subject: Re: UNIX trademark now X/Open Reply-To: cflatter@nrao.edu Date: Thu, 21 Oct 93 23:41:37 GMT In article 00@amdahl.uts.amdahl.com, fadden@uts.amdahl.com (Andy McFadden) writes: >In article hpa@nwu.edu (H. Peter Anvin) writes: >>In case you don't read comp.unix.misc, Novell has transferred the >>trademark UNIX to X/Open, who allows its use for any OS that follows >>the X/Open spec 1170. > >If I'm not mistaken, the spec requires that the code be based on USL's >code (somebody swung a sweet deal), and therefore to be called "UNIX" >you still have to pay royalties. This will not be necessary after the 1170 API is approved by X/Open. There is an interim arrangement in effect that allows vendors to call their O/S UNIX if it meets certain conditions, one of which is derivation from the USL sources. When the 1170 API is approved any O/S that has been certified to conform to the 1170 API (a superset of the XPG4 base API) may use the UNIX trademark whatever its lineage. Chris Flatters cflatter@nrao.edu ------------------------------ From: sjh@unixuser.chi.il.us Subject: Re: Andrew File System Date: Thu, 21 Oct 1993 23:49:14 GMT In jahoward@iastate.edu (Jim Howard) writes: >Does a port or complete rewrite of the Andrew file system (AFS) exist >for Linux? >Is such a project possible, if it does not already exist? >Is it something that people would want if it does not already exist? >If it does exist, where can I find information on it (either the product, >or the group working on it) ? >Thanks >Jim Howard >-- >*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_* >jahoward@iastate.edu SGI adm. ISU EE/IEEE >=-=-=-= LINUX -- Have you administered a real OS today? =-=-=-= >=============== IPRT/ICEMT--Black Engineering 95E--Ames Lab ================== Well, this doesn't seem real likely. Basically anybody with a source license for AFS could conceivably port it, but it's a commercial product - they couldn't sell it to you legally. You could get in touch with Transarc, the company that markets AFS and try to convince them that they could get rich with a Linux port, but I suspect they'll have real doubts about that. The port is likely to be non-trivial. ------------------------------ From: drew@kinglear.cs.colorado.edu (Drew Eckhardt) Subject: Re: ugly name for core dumps (core.imagename) -> patch for "img.core" Date: Thu, 21 Oct 1993 23:14:22 GMT In article , Rick Frankel wrote: >(Sorry about the null prev. message, I seem to be hitting a lot of >wrong keys lately :{) > >In article koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: > >koenig> I find it's a good idea to get "named" core dumps for each >koenig> image but the current naming convention in pl13 isn't that >koenig> good since - you can't find and remove all core.* files (some >koenig> people call source files core.c or core.h > >I agree, I have the same problem in pl12. core.[ch] is EXTREMELY >common (I think it's even in the gcc source), so it is very dangerous >to search and destroy core files wiht the current implementation I don't see the problem - if you are blindly assuming that every file named core* is a core file, the problem isn't Linux's naming of core files (agreed apon as the way core files should be named by the Berkeley Computer Systems Research Group, but too late for 4.4 BSD, Convex names core files core.programname.pid). The problem is your inability to write a script that does the appropriate sanity checking, ie something simple like : #!/usr/bin/perl open (CORES, "find / -name \"core*\" -print | xargs file |") || die "$0 can't run find : $`\n"; while () { /(\S+):\s*(\S+)/; if ($2 eq core) { unlink ($1) || print STDERR "$0 can't unlink $1 : $`\n"; } } BTW - in cases where users are doing development, you shouldn't delete core files from users home directories. Instead, have you script mail them with a polite suggestion to remove the core files found in their directory (with a list of the core files) when they nolonger need them, and to prevent messages like this, they should move the core files to something other than core.*. Implementing this is left as an exercise for the reader. --- Boycott USL/Novell for their absurd anti-BSDI lawsuit. | Drew Eckhardt, Condemn Colorado for Amendment Two. | Professional Linux Use Linux, the fast, flexible, and free 386 unix | Consultant Will administer Unix for food | drew@cs.Colorado.EDU ------------------------------ From: rideau@ens.fr (Francois-Rene Rideau) Subject: meta-fs device idea Date: 21 Oct 1993 16:27:51 GMT [this was a post to c.o.l a few days ago, when I didn't have access to the new hierarchy. I repost it now that I have been granted this access] Dear Linuxers, I use linux 0.99.13 (or is it 12 ? it was in the lx9913 package from Slackware 1.02 (or was it 1.03 ?) distribution, disk q1), and I am thinking about a new feature to add to the the kernel. Of course, I am too busy/lazy to do it myself (at least now), but I am willing to participate in a team that'd do it. The thing is an filter device (a la loop device, or in fs mounting options) over filesystems, that would allow --longnames--access rights--automatic compression/decompression--user-level mounting-- (well, at least longnames to begin with) over any filesystem transparently through a (hidden by default) [optional .]filterfs[optional .]rc (or anything) description file ? The filter will intercept calls to the file-system (that is file access), and interpret them after having read the resource file (a global one, and/or one local to each subdir). The name of the file can be set in mounting options and/or be such that any old filesystem can read it (i.e. FAT and minix). See the sample ressource file at the end of the message for features (the syntax of the sample may or may not be that of the resource files or of resource files sources through a simple compiler). Perhaps a full language can even be made available to interpret the file-system (then, a daemon would be needed to use the file system, and/or some limitations put in the interpreter for it not to loop). Of course, some sanity checks about resource files will have to be done before interpreting them and/or mounting the device, and utilities be released to check/correct/update/modify resource files before mounting filesystems. For example, assuming filterfs.rc is choosen as resource file name, an instruction \example{hardfile filter.rc is invisible} would be both a signature for the resource file and a useful instruction for the interpreter ! What would be the benefits of such a beast ? Why enhancing an old file systems and not building a new one ? An obvious objection against my approach is speed: if you want data compression on your system, this way of doing things will be slower than a file-system with builtin long names, access rights and ownership, and compression. BUT my approach gives you more than just that. You have a (? user-) customizable system for filesystem enhancement (assuming you use a daemon as do nfs partitions), and all that (particularly compression) using transparently a good old robust and portable filesystem (for example, FAT ;-} ) and you know how to recover in case of crash (the compression system is well-known, as should be the underlying fs, FAT or minix for example, ext2 one day). THIS, according to my own experience, is VERY important: I crashed ext2 filesystems four times, and had to reformat and restore everything (it's no fun reinstalling a 30 disks distribution then recustomize the system) reformat and lose all data, whereas I twice (once under linux - but I have been uncautious) lost FAT filesystems (ie lose some or all of system areas), and had no problems recovering most of it by hacking with a good dos-based sector editor) [BTW, is there some good sector editor under linux ?]. You also have earned the capability of running full linux with under a plain DOS partition (assuming you manage to mount the filtered partition). Imagine standalone software (games!) released with linux as a DOS extender (in fact, DOS replacer!). If the software is good and easily installable and spreads, more and more people will learn about linux and want it to replace DOS; they won't have to repartition their disk (they will once they're convinced !), etc, etc. So, is it feasible ? Is someone doing something like that ? Has something like that already be done ? If not, is there somewhere some existing code somewhere that would be useful for the implementation of that thing ? ### sample resource file ### # upper/lower cases # see makefile (not filtered) as Makefile (filtered). Makefile is hardfile makefile # long names THIS_IS_A_VERY_LONG_FILENAME._Yes,indeed_it_is_!!! is LONGFILE.000 RELEASE.234 is RELEASE_NOTES:please_DO_read # access rights Mail has rights 700 home/fare has owner fare, has rights 755 # generic remapping see *.cpp as {1}.CC # symlinks where unfiltered fs hasn't zap is symlink to ZAP # hardlinks even, now ! foo is hardlink to hardfile bar hardfile bar has 3 links : foo beltch zap ../bar # invisible unfiltered files is_invisible hardfile gollum # auto-decompressed file # (through temporary files in /tmp or as told in options) header_1000.h is zipped in headers.zip header_1001.h is zipped as foo/bar/zap/path/header_1001.h in # .zip is far better than .tar.gz, as you can access a file independently from # the others #auto-decompressed directory # /usr/include will shrink alot that way (8 !!! include is zip_file include.zip #concatenating directories usr/include is_appended inc441.zip home/sdr is_appended home/defaults #process-defined files... userfile is file $USER_FILE or_else /etc/userfile # etc, etc... ### End of sample ### -- -- , , _ v ~ ^ -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . ------------------------------ From: rideau@ens.fr (Francois-Rene Rideau) Subject: 1.72MB floppies Date: 21 Oct 1993 16:42:40 GMT My 0.99.9 had 1.72MB floppy support (i.e. I could mknod a /dev/fd0H1722), and used it much (together with the DOS FDFORMAT utility). But I upgraded to 0.99.13), and I can't have this device anymore. I looked in .../floppy.c, and no 1.72MB floppy format was found. I was disappointed, but happily found that Linux could still read (but not format - I must use DOS 8( ) my fdformatted floppies. Why is that ? Can I add an entry in floppy.c ? What values must I give to the gap1 and gap2 fields ? Thanks for any help. P.S.: BTW, is it possible to write a new format for lower density floppies whose external tracks would be formatted 500kbps, middle tracks 300kbps and internal tracks 250 kbps ? -- -- , , _ v ~ ^ -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . ------------------------------ From: rideau@ens.fr (Francois-Rene Rideau) Subject: developping an OO environment over Linux ? Date: 21 Oct 1993 17:13:00 GMT I am on a project of an OO environment, and I intend to use the i386 segmentation scheme to implement mutually protected objects securely. It would be great if I could build it on the top of linux, and not rewrite all the low-level I/O stuff... Is it possible (if it is, how, and at what point ?) to manage the descriptor tables (gdt,ldt) and share it between light-weight threads ? What control can I have over segmenting and over paging (i.e. can I use the usual copy-on-write & demand-paging device for some pages, but have my own manager for special pages ?) If there are some (little) changes to kernel needed to run it, how to do these and interfere as few as possible with further kernel evolutions ? Where to add these changes ? If I do build my project on top of linux, how to interface my assembler output with C library functions and/or the kernel ? Is it possible to link my current (MS-DOS) TASM .obj output modules with unix object modules (These files rely heavily upon TASM's macro-language, whereas GAS hasn't got anything like that; perhaps someone has got a good, powerful preprocessor, i.e. something else than this stupid cpp) ? -- -- , , _ v ~ ^ -- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban -- -- ' / . ------------------------------ From: Court Demas Subject: Re: Andrew File System Date: Thu, 21 Oct 1993 22:46:14 -0400 jahoward@iastate.edu (Jim Howard) writes: > Does a port or complete rewrite of the Andrew file system (AFS) exist > for Linux? > > Is such a project possible, if it does not already exist? > > Is it something that people would want if it does not already exist? > > If it does exist, where can I find information on it (either the product, > or the group working on it) ? AFS (Andrew File System) was originally created at CMU, but is now a product of Transarc. Last I heard, AFS was going to become DFS or something, so it doesn't seem likely that there's going to be much work on it. Plus, if there were it would probrably be commercial. AFS sucks anyways. Use NFS :-) > Thanks > > Jim Howard > > -- > *_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_*_* > jahoward@iastate.edu SGI adm. ISU EE/IEEE > =-=-=-= LINUX -- Have you administered a real OS today? =-=-=-= > =============== IPRT/ICEMT--Black Engineering 95E--Ames Lab ================== -court ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development) via: Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development Digest ******************************