Linux-Development-Sys Digest #352, Volume #8     Fri, 15 Dec 00 11:13:12 EST

Contents:
  Re: ramdisk: how much mem do they use? (Kasper Dupont)
  Re: changing BASH's path searching (Josef Moellers)
  Re: getty-less system? (Bryan Hackney)
  Re: Intel StrongArm SA1110 processor ("Geoff Winkless")
  Re: root disk: mke2fs failing (linux 2.2.14) (Kasper Dupont)
  Re: A faster memcpy and bzero for x86 (Johan Kullstam)
  Re: set hot key in single user mode (Kasper Dupont)
  Re: Kernel supporting more than 2GB of Ram ("Gene Heskett")
  Re: Selective disabling of page cache for mmap (Andi Kleen)
  Re: changing BASH's path searching ("Peter T. Breuer")
  Re: changing BASH's path searching (Kasper Dupont)
  Re: how to use "pthread_rwlock_t" in linux? (Kaz Kylheku)
  Re: changing BASH's path searching (Kasper Dupont)
  Re: testing read permission on an already open device (Kasper Dupont)

----------------------------------------------------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: ramdisk: how much mem do they use?
Date: Fri, 15 Dec 2000 14:01:41 +0100

Jerome Corre wrote:
> 
>  hi
> 
> I have 32Mb of ram on my linuxbox, I sometime use ramdisk (/dev/ram0 or
> /dev/ram1) to store small filesystem, prepare a bootdisk or when my
> system boot usimg initrd.
> I would like to know if it is possible to know how much memory the
> ramdisk are using. I suppose that they don't all use 4Mb as there are 16
> ramdisk i can use and I only have 32 Mb of ram. How can I found out how
> much memory they use? and if I don't need what is left on one of them
> after i unmount it how can I free the memory a ramdisk use?
> 
> thanks for any help
> 
> --
> Jerome Corre
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

You can get a quick but not exact information
from top. The memory is allocated using the
buffer system, with this litle memory there
probably will not be many other buffers
allocated. So the buff field is a reasonable
estimation.

-- 
Kasper Dupont

------------------------------

From: Josef Moellers <[EMAIL PROTECTED]>
Subject: Re: changing BASH's path searching
Date: Fri, 15 Dec 2000 14:41:23 +0100

"Peter T. Breuer" wrote:
> =

> Josef Moellers <[EMAIL PROTECTED]> wrote:
> > "Peter T. Breuer" wrote:
> =

> >> >> updatedb takes less than 2 mins on my P450.
> >>
> >> > You haven't seen what I've seen ... I'm not talking tens of gigaby=
tes
> >> > ...
> >>
> >> I'm talking 5GB.
> =

> > That doesn't even reach the size of our boot disk B-{) I'm talking 50=
,
> > maybe 500GB or more of mail files, news group articles, web pages, ..=
=2E
> =

> Then I misinterpreted your remark. I took you to mean that you were

Yes, I may have been unclear. Sorry for that.

> using less than 10s of gigabytes. But why are you running updatedb
> over them? Run it over /usr and / partitions (or whatever) only. That's=

> where your system files are. It should take about 1-2 mins.

We were discussing package information. And there an access to the rpm
database is clearly quicker (and with less impact on the buffer cache)
than a search through some directory hierarchy.

> > That may be your approach to installing a package on a single P450 ba=
sed
> > box. We have customers with >100 machines. Tell them to manually keep=

> > track of the modifications to make.
> =

> Thank you, but I run 100s of machines.  I certainly wouldn't ever do a
> single install, and I certainly wouldn't trust some installer to modify=

> any config files for me.  As it happens, my machines are debian boxes,
> and I do installs remotely using scheduled batch commands and dpkg with=

> a yes 'n' piped to its input, followed by md5sum tests and a voting
> procedure on the server that decides how to correct mistakes. All
> machines are tested for all files md5sums every day.

Ok. So what you're telling is that you indeed use some packager to
install packages and you say no to questions you haven't seen? Sounds
strange.

Anyway, It guess the bottom line is that you're unsatisfied with how
some (most/all) packagers handle the installation of packages and you'd
rather have more control. I'm quite satisfied with rpm.
But then ... I'd accept a binary-only driver module for some hardware
I'd like to use B-{)

-- =

Josef M=F6llers (Pinguinpfleger bei FSC)
        If failure had no penalty success would not be a prize (T.  Pratchett)

------------------------------

From: Bryan Hackney <[EMAIL PROTECTED]>
Subject: Re: getty-less system?
Date: Fri, 15 Dec 2000 07:42:50 -0600

Marty Ross wrote:
> 
> Using RedHat 6.2:
> 
> I'm trying to create a standalone system so I'm trying to understand how
> "init" works exactly.
> 
> If I say, for example, that my "standalone" program runs at "runlevel 4",
> and I insert a line
> into "inittab" that says:
> 
> myprog:4:respawn:/mydir/myscript
> 
> where "myscript" sets my environment, loads my daemon processes, and runs my
> application, the first daemon process I load gets terminated with "SIGTERM".
> Why?  By whom?  (presumably, by "init").  But I don't understand.  There IS
> a previous line in the "inittab" that reads:
> 
> l4:wait:/etc/rc.d/rc 4
[...]

If you don't want init, don't use it. With lilo, you can do something like
init=/bin/sh
to bypass init.

-- 
                                 Bryan Hackney / BHC / [EMAIL PROTECTED]

------------------------------

From: "Geoff Winkless" <[EMAIL PROTECTED]>
Subject: Re: Intel StrongArm SA1110 processor
Date: Fri, 15 Dec 2000 13:46:28 -0000

"Nils T. carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
: Can anyone tell me if there is a embedded Linux implementation for the
: StrongArm SA1110 processor.
: I also need the ip networking package.
:
: Of course, application development will be done using Linux on a
: workstation and a cross-compiler.

Take a look at http://www.armlinux.org/ and http://www.debian.org/ports/arm/

Geoff



------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: root disk: mke2fs failing (linux 2.2.14)
Date: Fri, 15 Dec 2000 14:55:38 +0100

Marty Ross wrote:
> 
> Please excuse if this is a duplicate; I don't see the post of this from
> lastnight, so I'm sending again...
> -----------------
> 
> I'm developing a new install procedure for a semi-embedded system, and I'm
> having trouble with the partition and format process.  I'm using out of the
> box RedHat 6.2 as my source/development system (kernel 2.2.14-5.0).
> 
> At first, I thought it was a hardware problem, but I've seen too many
> platforms on which the same problem happens in the same place to continue
> believing this.
> 
> I am building a minimal kernel--the last one I built was without
> modules--and have tried the various versions of the floppy and hard disk
> drivers just in case they were at fault.  I boot with my boot and root disks
> (that I built according to the "bootdisk HOWTO"), and then I insert a floppy
> containing "fdisk" and "mke2fs" (with all the necessary shared libs, as
> indicated by "ldd"), and partition the hard drive (/dev/fda), and then try
> to make filesystems.
> 
> It always seems to hang (completely dead; no "NumLock", etc.) at the end of
> the "mke2fs".  However, sometimes succeeds to format (it seems like always
> on the "inner" partitions of the drives).  On these partitions--even after a
> reboot--it crashes even accessing the drives (e.g. "cp -r /mnt/floppy
> /mnt/hda1", or "ls -R /mnt/hda1").
> 
> Is there some secret to this?  Maybe there's some dynamic library that the
> commands need for accessing the filesystem that it's not complaining
> about--just dying?  Again--I built the kernel with NO modules the last time
> and it acts the same way.  What could possibly give?
> 
> Anybody have advice on how to best construct an install boot/root disk for
> an embedded (custom) linux system?  What's real important here is
> convenience--it will be installed on literally thousands of machines by
> non-techies (hired hands in department stores).
> 
> Thank you very much for any helpful advice you can offer!
> 
> -- Marty Ross

It sounds to me like it is the harddisk driver which causes the
crash. There are different drivers you might try with different
and also try with different parameters, the harddiskdrivers
have many parameters.

A total lockup cannot be caused by a shared library problem.

Another posibility is that the kernel image have been corrupted
have you tried using different floppies/drives.

-- 
Kasper Dupont

------------------------------

Subject: Re: A faster memcpy and bzero for x86
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 15 Dec 2000 09:08:15 -0500

Kasper Dupont <[EMAIL PROTECTED]> writes:

> Johan Kullstam wrote:
> > 
> [...]
> > 
> > you can't just clobber the FPU regs, something else might be using
> > them.  the kernel cannot use FPU without saving and restoring them
> > since they could be used in a userspace program (save/restore FPU every
> > time you enter the kernel is too expensive, FPU is only save/restore'd
> > at userspace program context switches).  when you factor in the
> > overhead the FPU save/restore, using the FPU for memcpy suddenly
> > becomes less attractive.  MMX also uses FPU registers so the same
> > thing goes for that too.
> > 
> 
> The software raid detects MMX and uses MMX instructions
> inside the kernel if it is faster than a compiled version.
> That is for XORing datas which should be slightly more
> complex than just copying. Is there a good explanation
> why that should be a good idea then.

if the savings of using MMX justify the cost of save/restore on the
FPU registers, then MMX copy wins.  if not, it loses.  i was just
pointing out that you need to factor all your costs into the
cost/benefit analysis.  nothing more.

-- 
J o h a n  K u l l s t a m
[[EMAIL PROTECTED]]
sysengr

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.admin,comp.os.linux.development.apps
Subject: Re: set hot key in single user mode
Date: Fri, 15 Dec 2000 15:29:06 +0100

Josef Moellers wrote:
> 
> Brian Hui TT wrote:
> >
> > Hi,
> >
> > I am using Mandrake 7.0.  After I boot up in using single user mode, init 1,
> > I can not use some hot key like "CTRL+C" to terminal program. Can anyone
> > give me some idea how to initiate hot key function and where is the related
> > file. Thank you
> 
> The command is "stty intr ^C" (You can type it as a caret (^) followed
> by an upper case C, stty will understand this)
> I'm not sure if you can put it into any of the rc scripts, but as it's
> very short, why not type it?
> 
> --
> Josef M�llers (Pinguinpfleger bei FSC)
>         If failure had no penalty success would not be a prize (T.  Pratchett)

There is another possible explanation. If the shell
being run in single user mode is using /dev/console
you cannot use CTRL+C and CTRL+Z. The solution is to
use /dev/tty1 instead. Does anybody know where this
shell is being started, I cannot find it in the
configuration files.

-- 
Kasper Dupont

------------------------------

Date: 15 Dec 2000 8:41:8 -0500
From: "Gene Heskett" <[EMAIL PROTECTED]>
Subject: Re: Kernel supporting more than 2GB of Ram

Unrot13 this;
Reply to: <[EMAIL PROTECTED]>

Gene Heskett sends Greetings to Josef Moellers;

 JM> "[LsD]Tanis" wrote:
>> 
>> Hi guys, does anybody out there know where I can find a kernel for
>> an Intel Based Server with 4 GB of RAM?

 JM> Look for a kernel which includes the BIGMEM patches.
 JM> This patche enables the use of 4 GB of RAM.

Don't quote me, but ISTR thats been a checkmark available in make
xconfig for the last several kernel versions. Maybe not for that much
ram, but its at least related.

Cheers, Gene
-- 
  Gene Heskett, CET, UHK       |Amiga A2k Zeus040, Linux @ 400mhz 
        email gene underscore heskett at iolinc dot net
#Amiga based X10 home automation program EZHome, see at:#
# <http://www.thirdwave.net/~jimlucia/amigahomeauto> #
ISP's please take note: My spam control policy is explicit!
#Any Class C address# involved in spamming me is added to my killfile
never to be seen again.  Message will be summarily deleted without dl.
This messages reply content, but not any previously quoted material, is
� 2000 by Gene Heskett, all rights reserved.
-- 


------------------------------

From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Selective disabling of page cache for mmap
Date: 15 Dec 2000 15:34:14 +0100

[EMAIL PROTECTED] writes:
> 
> Possible solution:
> -------------
> a)
> using swapoff -a, thus disabling all paging. That of course prevent
> paging out to swap, but I was still observing a huge performance loss as
> the application cache filled up. vmstat did not show any page acticvity.
> I assume that part of my text segment could just be dropped and then
> just be loaded from the underlying file again. As vmstat shows no swap
> in's, I'm wondering if this situation just does not occur, or if those
> page faults just are not reported as "swap ins"

Does not help. It would not prevent your text pages from being thrown 
away (they are not swapped to the swap partition, but just thrown away
and reloaded from the executable file) 


> 
> b)
> would it be possible to introduce a new flag to mmap(), that will
> prevent the pages being mapped from being put in the page cache
> (something alike MAP_ANONYMOUS, just that it reads the blocks from disk
> on a page fault) ?

Check out madvise(2) in 2.4.


-Andi

------------------------------

From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: changing BASH's path searching
Date: Fri, 15 Dec 2000 15:30:42 +0100

Josef Moellers <[EMAIL PROTECTED]> wrote:
> "Peter T. Breuer" wrote:
>> Josef Moellers <[EMAIL PROTECTED]> wrote:
>> > "Peter T. Breuer" wrote:
>> using less than 10s of gigabytes. But why are you running updatedb
>> over them? Run it over /usr and / partitions (or whatever) only. That's
>> where your system files are. It should take about 1-2 mins.

> We were discussing package information. And there an access to the rpm

Well, we were discussing how you might inventory your disk.

> database is clearly quicker (and with less impact on the buffer cache)
> than a search through some directory hierarchy.


>> Thank you, but I run 100s of machines.  I certainly wouldn't ever do a
>> single install, and I certainly wouldn't trust some installer to modify
>> any config files for me.  As it happens, my machines are debian boxes,
>> and I do installs remotely using scheduled batch commands and dpkg with
>> a yes 'n' piped to its input, followed by md5sum tests and a voting
>> procedure on the server that decides how to correct mistakes. All
>> machines are tested for all files md5sums every day.

> Ok. So what you're telling is that you indeed use some packager to
> install packages and you say no to questions you haven't seen? Sounds
> strange.

I install on a lead machine, then duplicate the install instruction on
all others.  When I install (both first time and on other machines in
batch later) all questions from the dpkg mechanism are answered with no
(or more exactly, with carriage return, dpkg having been configured to 
be conservative on all machines).

If any departure from that procedure is required to achieve an
installation that touches no system configuration files at all, I file a
bug report of some kind.

> Anyway, It guess the bottom line is that you're unsatisfied with how
> some (most/all) packagers handle the installation of packages and you'd

Well, I have no qualms at all about slackware. I have always been very
satisfied with it, and have never had any problems (I run 3.0 still,
from after the great change to elf divide, just updated all the way).
I put debian on other machiens so that other admins have a chance of 
being helped by the knowledge built into the system. At least one gets
indications of what might be wrong from a dependency mechanism,  But I
certianly don't agree with an install modifying config files, and thus
I am happy with knowing what the executables and libraries installed
are, and nothing else. I am also happy not to know any dependency info,
as it happens, since I never have any problem finding it out (read
the %/& docs, or use ldd). 

> rather have more control. I'm quite satisfied with rpm.
> But then ... I'd accept a binary-only driver module for some hardware
> I'd like to use B-{)

I use them too. A little binary editing gets one a long way.

Peter

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: changing BASH's path searching
Date: Fri, 15 Dec 2000 16:00:14 +0100

Alex Graf wrote:
> 
> Instead of the shell searching for executables in directories listed in
> the $PATH shell variable, how about this:
> 
> for every subdirectory D from some constant base directory (maybe / ),
> do
>         if D has a subdirectory named "bin", then
>                 search for the program in there
>         end if
> end for
> 

Add this to ~/.bash_profile:

export PATH=$PATH:`find /usr -type d -name bin | tr \\\n :`

but be aware that you might create some security problems.

-- 
Kasper Dupont

------------------------------

From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: how to use "pthread_rwlock_t" in linux?
Reply-To: [EMAIL PROTECTED]
Date: Fri, 15 Dec 2000 15:17:46 GMT

On Fri, 15 Dec 2000 17:08:11 +0800, Victor <[EMAIL PROTECTED]> wrote:
>I want to use Process_shared "pthread_rwlock_t" in my program.
>
>But it seems that my Linux(Redhat 6.1) doesn't support it and always report
>compiling error "aggregate `struct pthread_rwlock_t rw_lock' has incomplete
>type and cannot be initialized".
>
>I found its definition in the  "/usr/include/bits/pthreadtypes.h", but it
>fellows
>a switch "__USE_UNIX98". Maybe it was not opened yet.

Read the /usr/include/features.h header for a clue.

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: changing BASH's path searching
Date: Fri, 15 Dec 2000 16:28:26 +0100

[EMAIL PROTECTED] wrote:
> 
[...]
> 
> I suppose since the exec*p() syscalls do path searching, this might be
> considered also a kernel issue.  But it's really a general issue of
> overall strategy.  You can just put packages in /opt/<packagename> and
> put symlinks as needed elsewhere.  Knowing what was put elsewhere is
> just a matter of examining all the symlinks for those that point to that
> particular package directory.
> 

There is only the execve syscall and that does not do
any path searching. The path searching is done by the
exec[lv]p wrappers in a shared library.

-- 
Kasper Dupont

------------------------------

From: Kasper Dupont <[EMAIL PROTECTED]>
Subject: Re: testing read permission on an already open device
Date: Fri, 15 Dec 2000 16:52:35 +0100

[EMAIL PROTECTED] wrote:
> 
> I'm looking for a function in the kernel that can be called for an ioctl
> to test to see if the current process has read permission on the device
> which is obviously already open, but may have been opened for write, not
> for read.
> 
> This ioctl will inject a string into the input of a virtual console as
> if typed on the keyboard.  Since it is customary to allow other users
> to have write permission to a tty device (e.g. to permit sending messages
> such as with the "write" command, or talk), the permission to inject
> input needs to be tighter than just being able to open the device.  It
> looks to me like the read permission is the way to go.  I could code up
> a test for owner, group, and supplementary group checks, but it would
> seem to me that such a test is likely to already be coded.  I did look
> around in the open code, but there, the test is done in a different
> context (the file isn't yet open).  In the ioctl context, the file is
> already open, so the information available is different.  Grepping for
> "obvious" keywords through the kernel code is quite a noisy experience
> and isn't turning up anything.  But then, I've found things with names
> I would not have anticipated, and this could be likewise.
> 
> I just don't want to be accused of "re-inventing the wheel" (since in
> this case I won't be making a wheel any more round than I suspect is
> already made).
> 
> And to try to head off a few more private emails from people who get the
> suddenly bright idea that since GPM can paste into the input, that I
> should just do what GPM does and not bother with my own ioctl, I'll let
> you know that I've already looked at that long ago, and no, it does not
> work that way.  Go read it yourself.  Hint: cut and paste data stays in
> the kernel; it is not transferred from process space.
> 
> --
> -----------------------------------------------------------------
> | Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
> | [EMAIL PROTECTED] | Texas, USA | http://phil.ipal.org/     |
> -----------------------------------------------------------------

Obviously the sys_read() function needs to check for
this and a quick look on this function found in
fs/read_write.c should give you all the information
you need.

And I definitely agree that the ioctl used by GPM
is not general enough, it would make much more sense
to have the buffer in GPMs address space. So we will
hopefully soon see a new version of GPM using your
ioctl.

-- 
Kasper Dupont

------------------------------


** 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 by posting to the
comp.os.linux.development.system newsgroup.

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
******************************

Reply via email to