From: Digestifier To: Linux-Development@senator-bedfellow.mit.edu Reply-To: Linux-Development@senator-bedfellow.mit.edu Date: Sat, 3 Sep 94 08:13:08 EDT Subject: Linux-Development Digest #111 Linux-Development Digest #111, Volume #2 Sat, 3 Sep 94 08:13:08 EDT Contents: [PATCH] APM BIOS patch (Stephen F. Rothwell) Re: lossage with "tar cz" writing to gzip; easy fix? (Chris Metcalf) Re: iopl() and access to CPU register cr0 (Laco Rusnak) Re: Aliasing `rm' (Christian Henry) Patch to setup.S for Cirrus CLGD54xx adaptors (Christoph Niemann) Re: PRIORITY make an undelete command (Kevin Grover) Re: scancode terminal support (was:Re: Linux console to SCO comp. prob) (Rob Janssen) Re: Any interest for DCF77 clock code? (Rob Janssen) Re: Any interest for DCF77 clock code? (Rob Janssen) Re: XFree & CDROM slow down transfer rate (Rob Janssen) Re: Linux - my first impressions (Rob Janssen) Re: DOS BC++/Linux floats (Rene COUGNENC) ---------------------------------------------------------------------------- From: sfr@pdact.pd.necisa.oz.au (Stephen F. Rothwell) Subject: [PATCH] APM BIOS patch Date: Thu, 01 Sep 1994 09:18:46 GMT Hi all, Below are diffs to implement the beginnings of the APM BIOS interface. (APM = Advanced Power Management) This patch is relative to 1.1.47 but should work on later kernels. So far this patch: - resets the system clock when suspend mode is exitted. - implements a device that can be read to get notification of all APM events. The major number of the device is auotmatically allocated - see /proc/devices. You need to mknod the device with the correct major number. This device can only be opened by one process at a time and only by root. Reads must be at least two bytes (each event is an unsigned short). I am just getting these out to let those who want to play have some fun :-). Please send me your ideas, comments and/or flames! Also, If you try this, please send me the boot time output (starts "APM BIOS ..." followed by some indented lines) as well as your machine name, model and BIOS revisions. The latter is important as some machines have upgradeable BIOS's and it is the BIOS that we are interacting with. Cheers, Stephen ======= Stephen Rothwell sfr@pdact.pd.necisa.oz.au NEC Information Systems Australia Phone: +61-6-2508747 Software Development Centre, Canberra, Australia Fax: +61-6-2508746 ===============snip==============snip==================================== begin 600 apm.diff.gz M'XL( .N892X" ZP\^U?;1K,_B[]B0THB8V,DFU?LD"\\G)0&#,!MI[28)E[90@MCS6?7XVM;6UC/(:+]REQTM;IBY M#W\[YIN.T6+FFS<[:_5Z_:DYM-&"$W+;8"VSL[/;V=D7R._?LZUVZTUCG]7% MQ_OW:ZQI3[T;G^W U7T0NLQ88S=N;+D\#?,&/I&.*G;@'5-;;&MC<%'SO[C3;P 1][Q(?6_'-A MP_1+H_"C;6\R/XC9(@*E;&[_,\B)-YVRC+O&0CUQ&S M?9>-AD.XXK&#N'5E%L=X8^=G.;JZ8"=#1C].X/(BQL$J#',OP=#A+O<"WIVS" M[7@1POWQ SNY#;TH#N:WK._QF>W[#<2^0!Z0>GO[EX7/:1ZFI[!-"?M>,!V$ M-S7 6JN_P%E(X\=GET.8GCMW'A@RS#.,^?R6^VP0Q+?W?#IMP!P/4OH73(\F MX?NY:SMQ<^XV?>YXD=T,_FK:BQH,H^&_8/W+4>\%&]WRB+-;6.XQCV,>P@>+ M;SF+;)#7CICG,]1:Q(%4!)@O/=^9+L!BWA*OVT[@3[R;YNT[4ENK;:#>6NUV MH[TK'.F/OS0_L.;1+ !'@.^SX+OVU5B:D\FWQDMC:=O:"^;R[QXXP!QTR'WP MRPRALU9'>4AR G7GA]K,.TN M7/[A:&[@MX:3AYA,[9NHQ&H;0-HM]#]P1A]6*WZ4=]!.NU7F9R_A1]@*>G7$ M;V:HT 3DX%N#CY<)"(R$#VP> '463";@%RGGK81S A2QH9+D/FC!S2 I(!1! M8-;(JV2,3;E_$]\FD <&$/,JB660?\!*%19DK9Y7"1B-!BXJ5H"!DB>3"2YI MR&$:GJ@Z6LSG01CC-9+(T42S Q?Q@WMVS]F]#0S$ 2-L^)R'00R+!/%CAL(T MFTWT*,V9 N\:8H'7@"N%BWD,L6(Z#>X!],7345+Z$KA<5?!*1Q^+CRG0/P^. M&>JC*=ML461LR80-P6'*7I][,]#H#/0+%@4: I'!:BZ.7[.3R_Z'LX_6Q=%O M%MQ@?H(Q?(AB/F.?V=G520HU_#+\#-_90P)U#;%I:[9SL$>>0P$ OFQ%P>X]/#;-&GMAP.H(3J'["<=KVJ,(G;368/( H*#^NK>Q.63HF;7ZI?'OTA$ MO*JQQ.V:P5J]2#0=<];J@BZX)CA5![-QV+1QE<15)Z'W++5G=%V$MOMI@Q?S$;@[$&$](!I$FH@T->)(=9 MH_>YUQ\--:UE*&1$U6J'HE8%&UY &2[*"] Z5:UV%/'9>,K#"A81DE2F0Y8. M0BOD-S7V.U0-E@5&:5G,LKX'4\@J4VY9^OJ4EC(M#BPJG'[W?X_7"4E;C[!- MV]A89R]92I#L69GS8V\D9-%)XH: K&E((<^3/:VQ#EL_M->9X*_6@&]C_(:8 M-&C -V,)M>.X5LO/,X1YKBY_[0VLX>AHU-.CV(YY,AM[SFQ"*'62?>1@3-^@ M"S3QFP/?B'35_*>#L\_ /P;GEWV=;"7!H-R=S438X4)>YG)NX(?CA F?DM8 M@2F*C'S,*>)ZJ$,US1SXYR[_D3H29L:"+YS-$9EY3_\G:Z*2WUU%%0/ OZ:Z5U,=]4,0WMNA"W'#F=JA*+"D)^&R0^V%$5#3 MJ#.SA!/KN8")T3$'&BV@;O/=-'3F!V.HV,1!1?J9*-JF)!QP:I!* U:,OVM M(#&S_PA"DEX.D00)+N5HK "+J#MX(>J&6* M1*>O[!"6Z6]BIR%_EQ)O@QD-]DKU3O9#)8\&*M4I"D=+[EY\_88=CM%LKZO@ M@E-],YBZ%E8CUFT0W-6JO56"8;53 ,L!,GV3=#A9^,[7;Q((YD;;E-$ S5]& M#;J48:!X32I0/G-P"GHE440"V^YF$;4_H%;EPW7_1-,C[R\>3/2$T1K;9H5; M7XUO(G*^%-V.4DPIN@9KR@S&MV><](RRKHOBF$GVUAOJ/<&GN.<'X0R2$2?BH52PYB]8\N>E3\Y'2@:45Q0M\ODV:PX# 8/3&^R)R5]B_6 M))A'4N5D*+3S/HTXOQ.;WC*R-W+C]Z 0N9^>W40PUPM3-!&7\XA>X,13@-!R M=VYZB81!L)!-3*LJ3F$0/OI/-+>[9Z(NJ*6RI5%8X^B1LEEH&J=>5;G9DUMJ%4]-T$ MFDENHJ\9.$;/'.,%+BE^2'F)LQ([DDUHKO07A;130Z,3Q%,FI&(2ENE;)A!9M5?J6FI5M ,&@+&/_)YBRIT M/9_1F2C;A7X*R9[*0K&23_82 @SU(:I)]HKA3FN-O8#,6B,_@P0*_-SIZVGO M"*RQ+!QQIF] _2S6 I@0=#:6O_L45*@J3"=D[]ZQ YPU63S*W]J/S%+,*BO) MUXX%J:FQITWY3)H7^3HA;RV8.Z"=M@A'I]_$DC/U=+HXN1X,,+QA&H:ES&\: MU, (RD4*4*?NMTBT+(I:0#\AR>-<%I@ 1G-\;Q7Y1IQ2^60^PKLFTWG1%*F! M;!%$NC#5LJK]@)#U$9)F[8DP5HI?*PQ?C6N:$M<4[_*#V)MX:74J765%>[_2 M20[1211;5N:B$$/ "+0\0/$*5B^A$E;J]8Q>R>52\:4;&4OA8,DDY%8)7TK< M-:J6976[QQ8^/NDNIP=5C?>WV-OH>A+XLZ6IY>*&&MI%..^FL75KJUM5:VE9 M:&9ORZ4&Z::LG) ['*I?EVU$8F$?TMA3K-?H\IMD!.J&)P@N_#L_N)<+FRD] ME2:I7S1I'7G&L?B$17G%LC)3S(]:PFJ@)@32-POC->&L/X2-^)[PL5!_E78/ MM<3,Q48I7\X]?'9]6.XA"-!U*RD4\4*\UZQ6=+-^82RL@+S8XSY#.ON[K,1 40=?"8 M4I,0UU2+V.J=]3\?G2>&HQ;)-1EM\/YDOO5N8B66<6GU+_O'9 _D9BFMHX]' M9WT* >@8F33YH@PZ;QQ"-8=\SNT8GTAK4LZM=Z+T.61X",@ZZX]Z@\'UU>CL M^+S73=C)L8EQX(6>H8.508OVBOU/>FN,*PEF( 72(HC3[F(J,S=M?01,L$(W M?JSF9W#=[Y_U/\HZ"Q]Y/T=,HN@!#5J5KA+J/?;N,%DC$?R$/%4+H::%7.,A MQ)CQF3-_L.)@$NED9*]DKLV3)U@89_7"Q$*[;*OB]@]I'AX85&*VZ;(+2]L2 M%DFF]XRER)G@H <%]& T_#)\),%*?ZO<'%SE<:+ -6P&%[8CI-[17U1 M_I4[C:4:.!-)8):**WR^O>$T-QS1Z5!5Q73YX#NANA'5DAI.7S%QKN2%GNRU M\5K 5X.7 2OJB?1^?CM5[0!65R'MEG5\-K*&UU=7EX.1[ [R+33Z=3](#B^) M9EH<70%I!+.Y_2=\^(!FL_9V:]=A$+:= M6TP50#C*'6MC1M,41,8+\*=( G%W^L!L9C8-@FX2R/:3Z[Y,NIH5( !A&D;> M#E %XM#:QK*S,5TR)^(WYAY\8RY

=ZQ>H@4(/E[XFG'<6["&F9>Q4TD'RM M^ZA0[P3'N1Z,&,2C:\!:0_ HOL@6HV)Z&"^RY8VR^<>.O8@"]IOV-&,\.4H-/Z(7'?F6AV-NW;*>6 M-OT%NJ#Q?T\:D1^A?OHON7;S7#]ARKCLPEF1@2F>A2OKC>WM@.N81FM'.&L5 M:*:*IZ%/5Q#^P; Y?9J=:MM[%F__#/5TQ90YL]96'!V .&$:IGIZH)NUS.5= MQPJO*D<4&1*?>49 ^L.]%T-(*6?:! MAMPKTW5Y[\! SD7]\A^V+DZ)1>MXTF3F^8N81^OJ!E52%M$C?1 IY#?00L!J M.+>AR[_K1H.M)UJ"B5_EGN9!V_AVY:.&#CNQ?3Q*AP>P'6QPQ1SR70-Q .TY MI=,CFV@K]L9@*/><'.1*K\FLE &Y;]:5.-D.T2%+KW%0'9![3UGZSXY=MX\A"RP"R?0#Y0#I_OTN'S7?E:3NGH MY_Q/SS%:>(JS-#8C.Z@>FMF^/!9:?5[YT>.B+Y/3SFSET=;"B!/MAOF :)5/CI#ZP/HZ.KGG5\_>$#Y,0&F\3VG,/L-V #DPD97 J=+C?N M>5)94P*'TJ=($ZH'X;= 20C#E.,,)65HZBSYQC1K2=5=2):8HV*-;*4U2DUM M%S6M6,TJD+)EKH)\[CGM1_&3@]K[G=9^9\:],Y[60?USH_ZU__1HK\ M.3L3D;^;GN,O:5=Z'^?T]ZWU:?] 8YVY4GO1*_:DT*A7Y7.;@O MS@.6-\WD@Q4*3&ANRR1P]"*TZ8#[\,L:7HGQY_ MT;1*C1+$]?"JUS]-( H*[5\.+H[.K4%O>'W1DR#M@HD/SD9G)T6@@LYA2:SC MH]&H-TAYV?''^456 NPC[RKG([V,0"LS@1Q_*N%(L'(UM&-654/5 MR&I!U.J8!QVSI;Q OT>OX^'' =4/E:^N>.(4J0^#W11$.6#ZW9ZR)5YDHW32 M@7/7"CDQTDV="T?TS8I#H')AC")?$8=UV\E4WVJ+5YWEBY#%).;RJ?U0 M66XNX@@/%%2.>0'NJ3[YCA);L=";^&[J1)9ZW15 !$*Y@$IJTX1JNFZ:K;0$ MQ?=KO BW>'$G<3%/7D.B-^>WY'M(#'IP?#-\"QYR=13P"5K&CG0'1FAG2'-;926W^+NR'PI4-\54M:1< M=U>4:(5J #A(.:?Y[,72$LV_)?^C 0#"8!;:,]>+[BQ\*"Q\8L2J^E-&PBB9_,KICE44#XJ4D*"Z*4? MN;91I%YZL9Q BX/)1JQ1ZBK\][XWN[;70$AZB"7L7>_&^SSS]GEF@B(=YR.N M$HX^'YF+NY0E:G*"IPQ#U-FVN]DOKP9#7J=#" M/';TPV8*3%^6OA@ DP[IVSSI>\;;U=DBRA5I4S]OK&A"J[!>@(['"5^"$5/. M<=]_U;&,U*>?CLZ]3X^V^ OB#BBOT9?CK0T#F55,VP\QTBBRH.=;)VAA0];Q MX4?-T".)EA1 ![<&V\T_>6P?\]M%M\L+3C..<]/6X7D*#_<;'LPJ*6[FLIYG M)IGI8W;YIJ6<9X\PKW+%"WL07H4]!BY>_5]H:9^F:S^=<&];N_8QJQ+A6'G$ M]RT)8@N^Q)_BKTYMDU8_Y#W)[&YC?9QL18S*#0ZS>'VDA"+,0\@1*MEE5!6$ M:MX47?V\O/X>#<]P3NW4! CIGE6>FZN!%SOC #I:9LR#8-$6+$KQL$[-.LT+ M>FXFM&I-HBIN18- MBUKF93M[MB4\%9</3" ./7MU!E?[##XK*S\X\]H+CA?VY")X\NY2JOP9TZA'.PV6I9YJB MZ?.DP*W=5XG90.0'*X0E5A+QG[E(N%EP2F\'B_$;%,7B5D;,38ZM">Z'&V#7 9!L2@Z<:F;@TYJOF%_W'0^@??\1!!*$X &\' end ===================snip================snip====================== ------------------------------ From: metcalf@CATFISH.LCS.MIT.EDU (Chris Metcalf) Subject: Re: lossage with "tar cz" writing to gzip; easy fix? Date: 2 Sep 1994 16:38:25 GMT I asked the other day about fixes to the "only wrote 4096 of 10240 bytes" problem with tar creating a compressed archive. I got one answer, from Bruno Haible (haible@ma2s2.mathematik.uni-karlsruhe.de), confirming that it's a problem with any POSIX system, since write() is free to return less than the requested number of bytes on an interrupt. Here's my solution (hack), which is to replace write() with a function that loops until it has written all the requested bytes. Users of tape drives that require exact blocking of writes should realize that this patch might mean that a partial write to the tape, which should be an error, won't be reported as such. People like me who just use tar for on-disk archiving don't have to worry about this (possible) problem. A better solution would be to replace only certain calls to write() with a wrapper function of the kind shown below. The maintainer of tar has been notified of this problem, and will hopefully include a more elegant solution than mine in the next release. --- 1.1 1994/09/02 03:40:20 +++ buffer.c 1994/09/02 03:43:13 @@ -1583,2 +1583,33 @@ return 0; } + +#ifdef __linux__ +#include +#define __NR_sys_write __NR_write +_syscall3(ssize_t, sys_write, int, fd, const __ptr_t, buf, size_t, s); + +ssize_t +write (int fd, const __ptr_t buf, size_t nbyte) +{ + int retval; + size_t done = 0; + while (nbyte > 0) + { + retval = sys_write (fd, buf, nbyte); + if (retval == 0) + break; + else if (retval < 0) + { + if (errno != EINTR) + return retval; + } + else + { + done += retval; + buf = (char *)buf + retval; + nbyte -= retval; + } + } + return done; +} +#endif /* __linux__ */ -- Chris Metcalf, MIT Laboratory for Computer Science metcalf@cag.lcs.mit.edu // +1 (617) 253-7766 ------------------------------ From: laco@Viktoria.drp.fmph.uniba.sk (Laco Rusnak) Subject: Re: iopl() and access to CPU register cr0 Date: Fri, 2 Sep 1994 11:49:08 GMT N J Andrews (N.J.Andrews@durham.ac.uk) wrote: : In article <33rnbe$nib@huxley.anu.edu.au>, gpg109@huxley.anu.edu.au (Gary Paul Gortmaker) writes: : |> The problem is that I can't access the 486 config register cr0. : |> I have used an iopl(3)/iopl(0) pair around the offending routine : |> (needed anyway, because I put a cli/sti pair around where it writes : |> to the i/o ports) but it still segfaults when it hits: : |> : |> 0x1c7b : movl %cr0,%eax : |> : From the manual page I can't see how iopl would enable you to access : the config register. Without spending time ( which I don't have ) : looking through reference books, I would have thought such a function : would have to be running in CPU supervisor mode ( note, this should : be distinct from super-user permissions ), which I would have thought : would have to be restricted to the kernel. You must be in kernel mode, i.e. have CPL (current privillege level) 0. IOPL has no effect to execute instruction move special,reg. So, if you have any possibility to change CPL to 0 in user program, it is possible to bring down whole system, if you made error. Laco. ------------------------------ From: henryc@reality.UUCP (Christian Henry) Subject: Re: Aliasing `rm' Date: 1 Sep 1994 10:51:55 -0400 Reply-To: henryc@io.org In article <1994Aug25.092203.18238@imag.fr>, Yves Arrouye wrote: > 1. Alias rm. What's bad is that when I used it under tcsh I spent my > time typing someting like '\rm ...' just to not use the alias (I hate > being asked if I really want to do what I said I want to do). I'm sure > I'm not the only one which did that... Why didn't you just pass the `-f' switch to rm (rm -f whatever)? ;-) ------------------------------ From: niemann@myhost.subdomain.domain (Christoph Niemann) Subject: Patch to setup.S for Cirrus CLGD54xx adaptors Date: 3 Sep 1994 11:16:11 GMT Reply-To: niemann@swt.ruhr-uni-bochum.de Hi! I have put a patch for setup.S (the realmode part of the linux kernel) onto our ftp-server ftp.swt.ruhr-uni-bochum.de in /pub/linux/cirrus. This patch allows users of Cirrus CLGD54xx adaptors to use the 132x25 and 132x44 video modes. The patch is against Linux 1.1.49. Please give it a try and mail any bugs/incompatibilities to me. I'll forward it to Ross Boswell, the original author of the patch. Happy hacking, Christoph -- ============================================================================= Christoph Niemann niemann@swt.ruhr-uni-bochum.de Lehrstuhl fuer Software-Technik Christoph.Niemann@linux.org Ruhr-Universitaet Bochum, Geb. IC3/36 Tel.: 0234/700-7982 D-44780 Bochum Fax.: 0234/700-6914 ------------------------------ From: grover@unlv.edu (Kevin Grover) Subject: Re: PRIORITY make an undelete command Date: Fri, 2 Sep 94 00:35:26 GMT on 26 Aug 1994 12:13:36 GMT, Glenn Maughan (glennm@hornet.sd.monash.edu.au) wrote: > Of course this will take up some disk space. But you could allocate a > maximum size for the hidden directory and older files are physically > deleted when the directory gets full. > Just a thought :-) Any hackers willing to give it a try? How about Athena "delete"? It marks files for delete by appending ".#" to them (which also convientently makes them invisible). delete is the actual program, the man pages gives aliases for rm and rmdir alias rm="/local/athena/bin/delete -F -e" alias rmdir="/local/athena/bin/delete -D -e" to make them behave as expected. lsdel lists all deleted files in current dir undelete used to recover marked files (before they are purged or expunged) expunge will really delete all marked files in the current directory (and possibly sub dirs if the -r option is used) purge cleans your entire account (prints all files and asks for confirmation first) All in all it works quite well. I've been using them on a Sun for quite a while. However, the require some wierd libraries to build and I never got them to work on my linux box. Maybe a more knowledgable Linux'er will feel like banging on it. -- - Kevin Grover, grover@isri.unlv.edu ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: scancode terminal support (was:Re: Linux console to SCO comp. prob) Reply-To: pe1chl@rabo.nl Date: Sat, 3 Sep 1994 09:48:50 GMT In <1994Sep02.031522.18885@ksmith.com> keith@ksmith.com (Keith Smith) writes: >It would be nicer if the scancode support for the keyboard was >integrated so that it could be used by the dosemu program, DOSEMU *does* use scancode support for the keyboard! > and/or >scancode terminals on serial lines. Oh, like SCO has . I'm not sure if it can do it on serial lines, but it would be easy to add. No need for support in the kernel for that. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Any interest for DCF77 clock code? Reply-To: pe1chl@rabo.nl Date: Sat, 3 Sep 1994 10:06:00 GMT In hm@ix.de (Harald Milz) writes: >No, Rob, it's been done. There's also a hint how to build a 5V-RS232 >level converter in the xntp-3.3 archive. A better one will be in iX 10/94. When I want to sync only a single machine from my clock (which already is interfaced to the RS232), can I configure xntp to leave out all the network stuff? I don't need another large daemon in my 16M system... How difficult is it to configure this? (I have been on the newsgroup for a while and I see a lot of problem discussion that extends way beyond what I want to do...) Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Any interest for DCF77 clock code? Reply-To: pe1chl@rabo.nl Date: Sat, 3 Sep 1994 10:08:59 GMT In koenig@nova.tat.physik.uni-tuebingen.de (Harald Koenig) writes: >yes! have a look on my small DCF77 program. since there are not much docs, >archie won't find it ;-) but it's available on > ftp.informatik.tu-muenchen.de:/tmp/dcf77-koenig.tar.gz Thanks! I will have a look at it! >it uses RX at 50 baud and, if available, DCD with a special kernel patch >for getting the times stamp in kernel and not in user mode (~12 usec >interrupt latency instead of ~10 ms before the user process gets scheuled) >and of course uses adjtime to correct the clock. I was considering doing that as well... too late :-) >PS: why do you want to use DCD for the DCF77 pulses? >the UART (16450/16550) samples the RX input with 16 times baudrate >(16*50baud == 800 Hz == 1.25 ms). so you get a jitter of 1.25ms with >every second pulse (plus 190ms delay after the leading edge for 1/2 start bit >plus 8+1 data/stop bits). on DCD you the an exacty interrupt for the >signal edges (~12 usec interrupt latency for a 486/DX2-66) That is why... Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: XFree & CDROM slow down transfer rate Reply-To: pe1chl@rabo.nl Date: Sat, 3 Sep 1994 10:30:28 GMT In stock@dutsh7.tudelft.nl (Robert Stockmann) writes: >Hello, >When running XFree and using a cdrom device I notice >that the transfer rate of my scsi disk slows down. >When not running XFree no decrease in transferrate can be observed. >If however XFree (openwin) is started the transfer rate is slowed down. >normally I get 5.6 Mbyte/sec but under X11 when /dev/sr0 is accessed >or has been accessed the transfer rate goes down to 500 to 700 kbyte/sec.. 5.6 Mbyte/sec on a CDROM?? You must be kidding... Even 500 to 700 Kbyte/s is top-of-the-bill, and not achievable with the drive you specify. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rob@pe1chl.ampr.org (Rob Janssen) Subject: Re: Linux - my first impressions Reply-To: pe1chl@rabo.nl Date: Sat, 3 Sep 1994 10:33:35 GMT In kjb@cs.vu.nl (Kees J. Bot) writes: >Under SunOS the installboot(8) program installs the bootstrap and the >addresses to /boot into the boot block. This only needs to be done >once, because /boot never changes. >The LILO method is rather crude. I don't think so... - LILO does not require the boot image to be on contiguous sectors - LILO can boot many different kernels and also other operating systems I think it is a good program, and running its installer after building the kernel is not a problem at all. It is even done in the same "make zlilo" command. Rob -- ========================================================================= | Rob Janssen | AMPRnet: rob@pe1chl.ampr.org | | e-mail: pe1chl@rabo.nl | AX.25 BBS: PE1CHL@PI8UTR.#UTR.NLD.EU | ========================================================================= ------------------------------ From: rene@renux.frmug.fr.net (Rene COUGNENC) Subject: Re: DOS BC++/Linux floats Date: 2 Sep 1994 19:40:19 GMT Reply-To: cougnenc@hsc.fr.net (Rene COUGNENC) Ce brave Riku Saikkonen ecrit: > I would like to use the MS-DOS version and the Linux version with the > same data files. Linux reads the MS-DOS fs well enough, but my files are > in a binary format. Basically, just a few structs written directly from > memory using fwrite(). Forget it. (You'll spend too much time with that). Apart from the internal binary format of your floats in DOS / Linux, you have to deal with the structure alignment in both systems and both compilers; you can do it; then you'll want to port your program to another platform, and have the same problems again... The best way is to use ASCII data files; (or use your own proprietary internal format). -- linux linux linux linux -[ cougnenc@renux.frmug.fr.net ]- linux linux linux ------------------------------ ** 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 ******************************