Linux-Development-Sys Digest #739, Volume #6 Sun, 23 May 99 04:14:08 EDT
Contents:
Re: best distribution (bill davidsen)
Re: 2.2.8 - Evil behavior (bill davidsen)
Re: New Project: Linux Upgrade Monitor (upgrademon) (Mario Klebsch)
Re: 2.2.9 kernel too big? (Amaury JACQUOT)
2.2.9 kernel too big? ([EMAIL PROTECTED])
Re: accurate timer - HELP! (Armin Steinhoff)
Re: extending the file system (Mark Hahn)
The World Wide Expo 7633 ([EMAIL PROTECTED])
Re: extending the file system (Dan Miner)
Workgroup (Wolfman)
Re: best distribution (Nix)
Re: Searching for Kernel Hacker's Guide (Mark Tranchant)
FAQ: glibc2 / libc6 and kernel 2.2.x (Mark Tranchant)
benchmarking file system. (Vijay Boyapati)
Re: i386 ENTER instruction problem (Linus Torvalds)
Re: Mac-emulation on Linux? (James Stafford)
Re: Using a shared library... Why won't my code compile. (Frank Sweetser)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: best distribution
Date: 22 May 1999 18:39:35 GMT
In article <[EMAIL PROTECTED]>,
Nix <$}xinix{[email protected]> wrote:
| My variant thereof I'm planning to make a little more, hmmm, overkilled,
| as these systems get attacked by several different admins (this is
| modified from my posting to the internal admins newsgroup here
| announcing the imminent change):
Sounds like a good plan for daily admin. Although I posted a very simple
example, you obviously can limit the find by directory, user, etc. The
only subtle part is using the change time rather than mod time, which
picks up modifications and changes in owner or permissions.
| The downsides are that it makes making changes more labourious, because
| that find command is not going to be fast :( and that, well, people can
| tell that *you* broke something now ;)
This is something like the RCS rlog feature, description of delta.
|
| Something *has* to be wrong with this system. It seems too *right*; it'd
| be more widely known than this if it didn't have some hidden, deadly
| flaw.
|
| Why didn't you mention this scheme a year ago, Bill? ;)
Old news, I first did it on PC/IX, SysIII for the IBM-XT, about 15 years
ago. Had to write my own find, cnewer was missing or broken. Of course
GNU find is missing the -local option from SysV find, so nobody has all
the features. -xdev skips mounts, -local skips only network mounts.
So you can chase every local f/s and ignore NFS/AFS?SMB mounts.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
One common problem is mistyping an email address and creating another
valid, though unintended, recipient. Always check the recipient's
address carefully when sending personal information, such as credit
card numbers, death threats or offers of sexual services.
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: 2.2.8 - Evil behavior
Date: 22 May 1999 18:41:38 GMT
In article <gd513.35066$[EMAIL PROTECTED]>,
bryan <[EMAIL PROTECTED]> wrote:
| but some of my installs on my systems were before I knew the trick to
| getting lilo to work on large disks. so the floppy boot was the only
| way to get linux started ;-)
|
| I think the easiest thing to do (on new installs) is make the first
| partition small (less than 50meg) and call it "/boot". then create the
| actual "/" partition in part#2. this way, you -force- the kernel to
| stay in the early part of the disk (in /boot). and lilo is happy.
|
| its a simple thing to do when you do new installs, but after-the-fact,
| its not always worth the effort to repartition.. hence the floppy
| boot method ;-)
You can put the kernel in a DOS partition, proving that there's one good
use for it;-)
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
One common problem is mistyping an email address and creating another
valid, though unintended, recipient. Always check the recipient's
address carefully when sending personal information, such as credit
card numbers, death threats or offers of sexual services.
------------------------------
From: Mario Klebsch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: New Project: Linux Upgrade Monitor (upgrademon)
Date: Sat, 22 May 1999 20:14:04 +0200
Nelson Minar <[EMAIL PROTECTED]> writes:
>RPM and Debian are not Linux specific - they both work just fine on
>other Unices. The only problem is that so far no one bothers to
>package much Solaris software that way. Build a tool that gives an
>incentive to use a package tool on Solaris, and the packages will come.
Why the hell should anybody want to use rpm on Solaris, since there
already is pkgadd? Using two different package systems on one OS only
leads to confusion.
If you wnat to go Solaris, you sould support pkgadd.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: Amaury JACQUOT <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: 2.2.9 kernel too big?
Date: Sat, 22 May 1999 21:39:38 +0200
bzimage is not bzip'ed but big zimage
you need to remove stuff from the kernel and compile as modules whatever
is not needed
to boot the system (think of parport zip drivers and the like)
[EMAIL PROTECTED] wrote:
>
> has anyone else had problems with the 2.2.9 kernel refusing to compile
> on an x86 redhat 6.0 box when using "make bzImage"?
>
> rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk
> ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
> make[2]: Leaving directory `/usr/src/linux-2.2.9/arch/i386/boot/compressed'
> objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/
> bvmlinux.out
> tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage
> Root device is (3, 5)
> Boot sector 512 bytes.
> Setup is 1292 bytes.
> System is 1041 kB
> System is too big. Try using modules.
> make[1]: *** [bzImage] Error 1
> make[1]: Leaving directory `/usr/src/linux-2.2.9/arch/i386/boot'
> make: *** [bzImage] Error 2
--
Ing�nieur r�seau Esitcom Membre d'APRIL
Avoid software piracy, use FREE software.
http://www.multimania.com/sxpert
http://www.april.org
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.setup
Subject: 2.2.9 kernel too big?
Date: 22 May 99 18:35:58 GMT
has anyone else had problems with the 2.2.9 kernel refusing to compile
on an x86 redhat 6.0 box when using "make bzImage"?
rm -f $tmppiggy $tmppiggy.gz $tmppiggy.lnk
ld -m elf_i386 -Ttext 0x100000 -e startup_32 -o bvmlinux head.o misc.o piggy.o
make[2]: Leaving directory `/usr/src/linux-2.2.9/arch/i386/boot/compressed'
objcopy -O binary -R .note -R .comment -S compressed/bvmlinux compressed/
bvmlinux.out
tools/build -b bbootsect bsetup compressed/bvmlinux.out CURRENT > bzImage
Root device is (3, 5)
Boot sector 512 bytes.
Setup is 1292 bytes.
System is 1041 kB
System is too big. Try using modules.
make[1]: *** [bzImage] Error 1
make[1]: Leaving directory `/usr/src/linux-2.2.9/arch/i386/boot'
make: *** [bzImage] Error 2
------------------------------
From: Armin Steinhoff <Armin@Steinhoff_de>
Crossposted-To: comp.os.linux.hardware,comp.realtime,comp.hardware
Subject: Re: accurate timer - HELP!
Date: 22 May 1999 11:21:25 -0700
In article <7i4ntv$83p$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
says...
>
>In article <[EMAIL PROTECTED]>,
>Vladimir G. Stanishev <[EMAIL PROTECTED]> wrote:
>)killbill wrote:
>)
>)> In article <[EMAIL PROTECTED]>,
>)> Dorin-Ioan Marinca <[EMAIL PROTECTED]> wrote:
>)>
>)> > How can I count the time (*less than 1us* - even x*10ns) very accurate
>)> > on Linux? I search something not depended on hardware or, if not,
>)> > something Pentium specific.
>)
>)honnestly I doubt that you'll be able to get to less than 1 microsecond
>)resolution. You may have already found the UTIME
>
>[snip]
>
>On PC hardware, the highest frequency clock which is directly visible to
>software (discounting those which a specific processor might provide)
>runs at 14.31818MHz/12 = 1.19318 MHz, giving 838 ns resolution.
That's true for the system timers ... but you have no chance to use that
resolution :-(
The real-time clock (RTC,IRQ8)is more practical. It goes down to 122.070 us ...
Armin
>
>Mike
>--
>----
>char *p="char *p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
>This message made from 100% recycled bits.
>I don't speak for Alcatel <- They make me say that.
------------------------------
From: Mark Hahn <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.networking,comp.os.linux.development,it.comp.linux.development,linux.dev.kernel
Subject: Re: extending the file system
Date: 22 May 1999 19:18:07 GMT
| I am goning to extend the file system of Linux to enable file sharing
| over the Internet. The goal is to let files in a remote computer be
| assessed as if they were in the local file system.
how is this different from NFS, SMB or Coda?
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To:
comp.os.linux.hardware,comp.os.linux.m68k,comp.os.linux.misc,comp.os.linux.networking,comp.os.linux.portable,comp.os.linux.powerpc,comp.os.linux.setup,comp.os.linux.x,comp.os.lynx
Subject: The World Wide Expo 7633
Date: 22 May 1999 19:36:15 GMT
voskyxupefprrncchlgzkoxkkmpxeiuncxjxvwfryih
------------------------------
From: [EMAIL PROTECTED] (Dan Miner)
Crossposted-To:
comp.os.linux.networking,comp.os.linux.development,it.comp.linux.development,linux.dev.kernel
Subject: Re: extending the file system
Date: 22 May 1999 19:45:07 GMT
Bush Chui ([EMAIL PROTECTED]) wrote:
: I am goning to extend the file system of Linux to enable file sharing
: over the Internet. The goal is to let files in a remote computer be
: assessed as if they were in the local file system.
: Can this be achieved? If it can, where should I start? (I am new to
: Linux programming.) Is there any book or web site that can provide me
: information?
: Thanks.
I suggest you investigate all of the file systems for Linux. You'll find
that there are a few of them already.
NFS (mostly UNIX)
Coda (totally new)
SMB/Samba (LanManager/MS file and printer sharing)
These are just the obvious systems which are "just lying around". You can
find all of them in the newer 2.2 kernels.
Happy hacking,
Dan
--
Dan Miner [EMAIL PROTECTED] | | Doing
Programmer/ | | Linux
Linux Consultant | "What yonder light Windows 95 breaks?" | since
http://www.nyx.net/~dminer/ | "Free software: The New Frontier" | v0.12
------------------------------
From: [EMAIL PROTECTED] (Wolfman)
Subject: Workgroup
Date: Sat, 22 May 1999 22:47:26 +0200
Recently I have created a homepage for linux development and now I still
need a few visitors to join the projects and give me feedback! Please
come to my small but nice page!
Have a short look at my sponsors to keep my services free!!!
--
Visit my Homepage @ http://Linux.XPage.nu
and have a short lock at my sponsors!!!
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: best distribution
Date: 22 May 1999 23:03:17 +0100
[EMAIL PROTECTED] (bill davidsen) writes:
> Sounds like a good plan for daily admin. Although I posted a very simple
> example, you obviously can limit the find by directory, user, etc. The
Directory limits are essential; we do not want to scan /proc, and we
likely don't want to go below /home either, or parts of /var/spool.
> only subtle part is using the change time rather than mod time, which
> picks up modifications and changes in owner or permissions.
Indeed.
I'm probably going to extend this even more to make it a general
`change-in-fs' reporter; a bit more awk should do that. So it can tell
you not just that `this file has changed' but exactly what has changed;
`it is six bytes larger and is now suid', or `this file is new' or `this
one has been deleted'.
I wrote such a tool for OS/2, long ago; it says something about the Unix
toolset that the Unix variant, as well as doing more, will likely be
about 500 lines of sh and awk rather than 2000 lines of C...
... when I've got it working nicely I may even GPL and release it. You
never know.
> | The downsides are that it makes making changes more labourious, because
> | that find command is not going to be fast :( and that, well, people can
> | tell that *you* broke something now ;)
>
> This is something like the RCS rlog feature, description of delta.
Indeed, only this is a filesystem delta. (Indeed the OS/2 program was
even called `fsdelta'...)
> | Why didn't you mention this scheme a year ago, Bill? ;)
>
> Old news, I first did it on PC/IX, SysIII for the IBM-XT, about 15 years
> ago. Had to write my own find, cnewer was missing or broken. Of course
! :)
> GNU find is missing the -local option from SysV find, so nobody has all
> the features. -xdev skips mounts, -local skips only network mounts.
> So you can chase every local f/s and ignore NFS/AFS?SMB mounts.
I have a horrible feeling that I'll need to Do Something about automount
points, too. In the first version I think I'll just trust people to put
them in the exclusion list. Normal network mount points it is probably
wise to exclude, too, or running this gets too damned slow.
This should be fun. :)[1]
[1] and well documented. I'm a literate programming freak, so this is
being done in noweb. (The code itself is /bin/sh with bits of sed and
awk.)
--
`As promised, here's the patch to do this. Not only is it good (it
compiles), but it is perfect (it boots). Up 9 minutes so far without
problems.' --- Richard Gooch on linux-kernel
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Subject: Re: Searching for Kernel Hacker's Guide
Date: Mon, 17 May 1999 10:27:49 +0100
Reply-To: [EMAIL PROTECTED]
Michael Powe wrote:
>
> >>>>> "Soohyung" == Soohyung Lee <[EMAIL PROTECTED]> writes:
>
> Soohyung> I wanna get Postscript version of Kernel Hacker's
> Soohyung> Guide.. Can you help me..? Any help will be
> Soohyung> appreciated.. Thanks in advance..
>
> Hmm, it says right on the Kernel Hacker's web page that it's only
> available in html. So, if you did find a ps version, it'd probably be
> out of date.
>
Load it into a browser and "print" it to a file as Postscript.
Mark.
------------------------------
From: Mark Tranchant <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: FAQ: glibc2 / libc6 and kernel 2.2.x
Date: Mon, 17 May 1999 11:47:23 +0100
Reply-To: [EMAIL PROTECTED]
Lots of people seem to have the idea that glibc2 must be installed to
use a 2.2 kernel. This is not the case. I suspect the confusion comes
from the Documentation/Changes file which advises on preferred levels of
libc5 and libc6 (glibc2) for use with a 2.2 kernel.
What this is saying is "*if* you have libc5, it should be libc-5.4.46 or
better" and "*if* you have libc6, it should be libc-2.0.7-pre6 or
better". It is *not* saying "you *must* have libc-2.0.7-pre6".
Hope this helps someone. Perhaps a change to Changes may be in order.
Mark.
------------------------------
Date: Sun, 23 May 1999 12:58:46 +1000
From: Vijay Boyapati <[EMAIL PROTECTED]>
Subject: benchmarking file system.
Hi guys,
I want to bench mark the performance of a file system (minix). I
basically want to keep track of how many times certain functions get
called (and how much total time they take) --- ie the inode_operations
defined in file.c in the /minix directory under /usr/src/fs.
I want these statistics to be available in a file in /proc for viewing
on demand.
My problem is: How can you determine when an inode_operation is called.
My idea was to redefine all the inode_operations (in the
inode_operations structure in file.c) to point to functions I define and
have those functions call the actual inode_operations (so I can do the
benchmarking in between).
The problem I am having is that not all the inode_operations are defined
(they are NULL) meaning that they default to some default
inode_operation defined somewhere in /fs. My question is, how do I find
out where these default operations are. I don't really know which file
to look in. If I cant find them then I can't get my functions to call
the appropriate inode_operation, cause I don't know their name!.
Hope this makes sense.
thanks in advance,
Vij.
please forward any reply to [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Linus Torvalds)
Subject: Re: i386 ENTER instruction problem
Date: 23 May 1999 06:20:34 GMT
In article <[EMAIL PROTECTED]>,
Joris van Rantwijk <[EMAIL PROTECTED]> wrote:
>
>Kernel 2.2.7 still has the same problem.
As has been mentioned by others: it's not a problem, it's a feature.
Linux will refuse to extend the stack beyond the stack pointer. Using
memory under the stack pointer is not considered acceptable, so you
should never do something like this (pseudocode):
*(esp-128) = val;
esp -= 128;
because it just sets you up for bugs when a signal comes in and trashes
what you had on the stack.
"enter" is a special, and very ugly x86 instruction that does exactly
the above. It so happens that we _could_ allow it, but as others have
mentioned, using "enter" in the first place is just stupid anyway, so
there really isn't any reason to allow that kind of braindamage.
>I did some more tests and found out that in my case (2.2.7 on i486) the
>problem only occurs when reserving more than 28 bytes of local storage
>(ESP gets decremented by more than 32).
Indeed. Linux allows a small amount of slop underneath the stack
pointer, because "pusha" has the same problem, and for "pusha" there is
no good alternative way of doing the same thing.
>I think this may be related to the following code from the kernel
>linux/arch/i386/fault.c (line 124) :
> /*
> * accessing the stack below %esp is always a bug.
> * The "+ 32" is there due to some instructions (like
> * pusha) doing post-decrement on the stack and that
> * doesn't show up until later..
> */
> if (address + 32 < regs->esp)
> goto bad_area;
Exactly. The comment pretty much says it all.
>The enter seems to check page availability for the entire stack region it
>claims
No. I think "enter" claims page availability for just the last byte it
claims, not the whole region.
> (which is odd since it only needs to access the upper 4 bytes,
>but then again the intel docs do say that it checks the SS limit for the
>entire region).
"enter" is just basically a horrible crock, and should not be used in
any case. It's slower than the (much more natural) alternatives, and
generally just doesn't have any redeeming features at all.
>My guess is that Linux simply doesn't support the ENTER insn (I think GCC
>doesn't use it).
Sure, you can use it, but you can't depend on Linux being nice to you
and extending the stack automatically. If you extend the stack by hand
before using enter, you can then use it if you want (another way of
saying "if you really know what you're doing, Linux lets you shoot
yourself in the head if you want to"). The example could be something
like this:
/* allocate 32kB of stack space */
subl $32768,%esp
movl $0,0(%esp)
addl $32768,%esp
/* now you can use enter to your hearts content */
enter 256,0
but it's not as if I really see the reason for doing something like the
above ;)
Linus
------------------------------
From: James Stafford <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.misc,comp.os.linux.powerpc
Subject: Re: Mac-emulation on Linux?
Date: Sun, 23 May 1999 00:45:37 -0700
>
> :>2. Buy a Macintosh and dual boot with Linux/MacOS
>
> : This is also a viable option, but somewhat more expensive :)
>
> Might save the most headache because some of the things may not work
> otherwise, and then these students probably want to concentrate on
> learning and getting their A's instead of fighting over something not
> their fault. Of course, the hackers among them would find it fun.
This is what I did for my last computer class that required a Mac. I bought an
old Power Mac, upgraded the RAM, and didn't have to worry about getting my
homework done. I think that Executor is a great program, a old trail version of
Claris Works seemed to work fine with it, but what abnout the other programs I
might need to use? Director and etc. might not work.
jamess
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Using a shared library... Why won't my code compile.
Date: 22 May 1999 09:49:07 -0400
Kevin Burton <[EMAIL PROTECTED]> writes:
> Warning. I just starting out with C/C++ on the Linux platform... here
> goes.
>
> I am trying to use a library: libftp. Only problem is that I can't get
> it to work.
a C library, linking with our C++ code?
> Here is my code:
>
>
> --
> extern void ftpInit(void);
first off, isn't there a .h file for this ftpInit library you should be
including? also, you can try
extern "C"{
extern void ftpInit(void);
}
> int main(){
>
> //ftpInit();
>
> }
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
Oh sure, it's doable. It's just a mere matter of programming. :-)
- Ted T'so
------------------------------
** 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: [EMAIL PROTECTED]
You can send mail to the entire list (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-System Digest
******************************
