Linux-Development-Sys Digest #217, Volume #8 Sun, 15 Oct 00 20:13:12 EDT
Contents:
Re: executing applications without using filesystem ([EMAIL PROTECTED])
Re: What is /boot/System.map ? (Ben Caradoc-Davies)
Re: Driver Loading FPGA Device ([EMAIL PROTECTED])
low-level I/O details with memory-mapped I/O on Intel architecture (John J. Willey)
Re: A new directory hierarchy standard - need opinions ([EMAIL PROTECTED])
Re: A new directory hierarchy standard - need opinions ([EMAIL PROTECTED])
LINUX DEVELOPER NEEDED ASAP - Dallas, Texas ("Shane Hairston")
Remote Shell ("Steve Wamsley")
Re: LILO version 21.6 released (Rudi Sluijtman)
Re: A new directory hierarchy standard - need opinions (Todd Knarr)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: executing applications without using filesystem
Date: Sun, 15 Oct 2000 18:45:05 -0000
In comp.os.linux.development.system The Ghost In The Machine
<[EMAIL PROTECTED]> wrote:
| If one does want to completely load an executable prior to actual
| execution, the simplest method would be to copy/load it into a temporary
| file on a ramdisk somewhere, then execute it from there. However,
| this option requires a mountable block device (ramdisk being one) -- and
| Linux's ramdisk (AFAIK) has the problem that it must allocate all memory
| pertinent thereto at the start of kernel execution and, once it runs out,
| it can't allocate any more. Sucks!
The ramdisks are allocated in the buffer cache. The ramdisk size (which
can be set in the kernel image via compile config or "ramsize" command,
or via the ramdisk= or ramdisk_size= kernel arguments) sets a ceiling
on the size of each ramdisk. I just booted a test machine which has
384 MB or real RAM and 128 MB of swap space to have 262144K of ramdisk.
That's a 256 MB ceiling on each ramdisk at the moment. I could hose
this system by filling up (try to, anyway) just two of them.
Just tried it. It froze. SysRq to the rescue :-)
| Even worse, ramdisk memory isn't available for caching (again, AFAIK).
It is cache. It lives there. There's an ioctl to release it.
| Someone may have hacked something up a la Amiga's ramdisk (which dynamically
| allocates more RAM as required), but I don't know much about it. It
| would be a nice capability, though, if a bit esoteric (Linux uses RAM
| as a file cache, so ramdisks aren't usually necessary on
| disk-based workstations). Or perhaps Linux's ramdisk does indeed
| allocate as it goes to a certain fixed size, so a big ramdisk wouldn't
| necessarily suck memory from applications.
The ramdisk is allocated in RAM as written at the device level, when you
would initialize it as a filesystem.
I run my systems with /dev/ram10 mounted as /ram and symlink some of the
directories from /var over to it (lock, pid, run, sock).
Tastes great! Less filling!
| In my opinion, an extensible ramdisk like the foregoing would be ideal
| for your application, assuming sufficient RAM. One might even be able
| to make the files on the extensible ramdisk non-RAM-cacheable
| (there's not much point, obviously).
What you have to commit to is the filesystem size when you initialize
it with mke2fs or whatever. But there are 16 ramdisks, so if one is
not enough, make another one.
There are layers of size commitment:
1. Compile a kernel with a default maximum size.
2. Change the size in the kernel image with "ramsize".
3. Change the size in LILO with append="ramdisk_size=whatever"
4. Change it at boot time by typing at the LILO prompt.
5. Initialize a ramdisk filesystem to the size you want up
to the maximum specified by 1-4 above.
6. Release too big ramdisk with ioctl(fd,BLKFLSBUF) after unmounting it.
I recall a program existing to do this, but could not find such.
For fun, read /usr/src/linux/drivers/block/rd.c
| I'm curious as to that, too, if only because the Amiga's ramdisk
| device didn't have a fixed size and I kinda liked that. :-)
I suppose a memory filesystem might be nice. My OpenBSD box has such.
On the other extreme, I'd like to have a ramdisk that behaves much MORE
like a real hard drive by supporting partitions. But then, I'd like to
see nested partition support in all block devices, including loopback
and networked.
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Ben Caradoc-Davies)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: What is /boot/System.map ?
Date: Sun, 15 Oct 2000 18:56:30 +0000 (UTC)
On Sun, 15 Oct 2000 19:47:48 +0200, J.Smith <[EMAIL PROTECTED]> wrote:
>I just did a kernel compile on my linux system, and noticed, besides the
>bzImage of course, a file called 'System.map'. I know I have to copy it to
>my /boot dir, just like the kernel image, but I was just wondering what this
>file exactly *is* and what it is needed for.
/boot/System.map is used by ksymoops to convert addresses (in kernel oops) into
symbols.
man ksymoops
>Does lilo need it?
No.
>Is it needed for loadable modules?
No.
>Do other applications use this file?
There is nothing stopping them. :-)
>And if I have two
>kernels installed, I will also get me two System.map files, where each is
>specific for the kernel it was compiled with. So how does the kernel or
>other programs know which System.map to use then, if for example we have 2
>kernels in /boot, like:
>
>A) "vmlinuz.2.2.13 & System.map.2.2.13"
>B) "vmlinuz.2.2.16 & System.map.2.2.16"
/boot/System.map is a symbolic link to the appropriate map file. You can do
this by hand, or in the case of recent RedHat releases, this link is updated at
boot time by the following in rc.sysinit:
if [ -L /boot/System.map -a -r /boot/System.map-`uname -r` ] ; then
ln -s -f System.map-`uname -r` /boot/System.map
fi
--
Ben Caradoc-Davies <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Driver Loading FPGA Device
Date: Sun, 15 Oct 2000 19:06:50 -0000
On Wed, 11 Oct 2000 23:31:05 +0100 Jonathan Buzzard <[EMAIL PROTECTED]>
wrote:
| Ideally you want a single kernel module that provides a driver for your
| card. The problem is that if you have lots of space taken up in the
| driver with information to program the FPGA it will take up kernel
| memory space which is not good. Also you want to avoid having to run
| user space programs so fire data at the FPGA before it can be used.
|
| Now marking it with __initfunc may cause the memory to be released after
| it has been run. That's the idea behind __initfunc at least but I don't
| know if it causes variables to be released, but code is for sure.
Doesn't the static attribute on variables make them part of the code?
| Alternatively using two modules, the kernel will unload the FPGA upload
| module after a couple of minutes freeing the kernel memory space. You
| could even have the module upload to the FPGA and then fail initalization
| so it never gets properly loaded. A second module the provides the
| driver proper.
Depending on when it needs to be loaded, one option is to load it from
a /linuxrc program which has the data in initrd. That way it would be
there before init starts (if that's when it finally needs to be present
and running).
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (John J. Willey)
Subject: low-level I/O details with memory-mapped I/O on Intel architecture
Date: Sun, 15 Oct 2000 06:09:07 GMT
I understand that the port I/O instructions IN, OUT, raise
an additional signal on the address bus to indicate that
the address refers to I/O space rather than memory space.
However, with memory-mapped I/O I have not been able to
locate information about the mechanism whereby 'foreign'
memory, residing in ROM or peripheral devices, is
distinguished from system RAM.
That is, when memory-referencing instructions operate on
non-system memory that has been configured through memory-
mapping initialization via the undocumented system BIOS,
what control or signal redirects the data transfer to the
foreign memory/registers in ROM or, for example, a PCI-
connected peripheral?
How is the foreign memory "tagged" to distinguish it from
a simple erroneous attempt to reach nonexistent system RAM?
How does the 'foreign' memory announce itself electronically
and thus make itself available to the CPU's memory-manipulating
instructions?
If this is the wrong forum for such a basic question, might someone be
able to direct me to a more appropriate group?
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: Sun, 15 Oct 2000 19:21:40 -0000
In comp.os.linux.development.system Todd Knarr <[EMAIL PROTECTED]> wrote:
| Convention. /opt is broken down per-package. If you aren't referencing
| the /opt/{package} directories directly, you usually make a link from
| /usr/{bin|lib|...} ( or /usr/local/{bin|lib|...} to the appropriate files
| under /opt.
|
| Frankly I find /opt a kludge, but it's a reasonable solution when
| dealing with packages that like to own their entire directory tree
| and don't co-exist well in the same directories as other packages.
When a package has more than a few executeables, or any libraries or
data it needs to access, I prefer having the whole package "encapsulated"
where I can see where it is, how much space it all takes, remove it all
if I want, or tarball it to another machine to run it there.
The disadvantage is that a package may need to have some files shared
between many machines and some files separate per machine. Perhaps
the best solution would be /usr/opt and /var/opt. Those can either or
both be mounted as distinct filesystems as desired.
|> 3) Another /opt/ issue... /opt/ is described in section 3.8 of the
|> current FHS as a place for "add-on application software
|> packages". I interpret "add-on" to mean "not essential to system
|> operation". In light of this, why do we have /opt/ , instead of
|> /usr/opt/ and /usr/local/opt/ ?
|
| Because either would be exactly equivalent to /opt?
Maybe. See above for /var/opt. But I'll extrapolate into /usr/local/opt.
I usually leave /usr mounted read-only and /usr/local mounted writeable.
The latter is where I make frequent changes, such as packages I am doing
on my own. I would prefer to put a vendor or community supported package
in /usr/opt and put a package I'm testing or developing in /usr/local/opt.
Then I would use /var/opt and /var/local/opt accordingly (probably one
filesystem, but it keeps patterns consistent).
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: Sun, 15 Oct 2000 19:37:10 -0000
In comp.os.linux.development.system Equinox <[EMAIL PROTECTED]> wrote:
| Therefore,
|
| 1) /opt/ would be for large, complex packages that were required by
| the system (not too many of these, if any at all -- hence my earlier
| language suggesting that perhaps /opt/ shouldn't exist). This also
| raises the question, would "opt" be a fitting name for this directory?
|
| 2) /usr/opt/ would be for large, complex, non-vital packages that were
| provided by the maintainers of the distribution.
|
| 3) /usr/local/opt/ would house large, complex packages added by the
| local sysadmin.
That makes a lot of sense, but I need yet another. Under the above
description I would want to mount /usr/local/opt/ read-only, yet I
want one I can leave openly writeable (which I have been doing with
/usr/local so far).
As long as packages are stored in {prefix}/opt/{packagename}/ then
I see no real problem in intermingling what is installed from the
distribution and what is installed later either from the distribution
CD, from the distribution vendor's web/ftp site, or packages from
entirely different vendors. As long as there is no name collision,
I don't see the problem with having multiple vendors in /usr/opt.
One aspect of this to consider is that distributions do vary and
what may be only obtained from a separate vendor for one distribution
may be included in another. Some distributions are just mediums for
other vendors, anyway, and as a sysadmin, I pick and choose all along.
Consider also that you may upgrade a package by installing a whole new
version. The original may be in the distribution, but you get the new
one directly from the original vendor.
To me the important distinction between /usr/opt and /usr/local/opt
is the way I can manage those spaces, such as mounting /usr/opt in
read-only mode, and mounting /usr/local/opt in no-atime mode. I'm
all cozy with installing packages of my choosing from a mix of vendors
into /usr/opt. That feeling isn't there for the likes of /usr/bin.
To me, /usr/opt should be more for install it and forget it. Then
I would be working with what is in /usr/local/opt on a more regular
basis. It would make sense for 4 distinct areas, but we only have 3
names at present to work with, and adding a 4th would be troublesome.
| True. Most of X's problems lie in the scrambled internal structure of
| the package. But it still needs to be located in something like an
| opt/ directory. It just seems like having the X11R6 directory
| directly under /usr/ is messy.
I would agree. Package name space should not be mingled with system
functionality name space, within /usr. So /usr/opt is a functionality
and within it are package names (preferrably package-version and have
package -> package-version for the active version).
--
| Phil Howard - KA9WGN | My current websites: linuxhomepage.com, ham.org
| phil (at) ipal.net +----------------------------------------------------
| Dallas - Texas - USA | [EMAIL PROTECTED]
------------------------------
From: "Shane Hairston" <[EMAIL PROTECTED]>
Subject: LINUX DEVELOPER NEEDED ASAP - Dallas, Texas
Date: Sun, 15 Oct 2000 14:55:24 -0500
ATTN: LINUX DEVELOPERS!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
If you have Linux desktop application development experience and are looking
for a great job, please EMAIL me at [EMAIL PROTECTED]
Thanks,
Shane Hairston
Technology Consultant
SRT Inc.
Dallas, Texas
www.srtinc.com
------------------------------
From: "Steve Wamsley" <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.c-programming
Subject: Remote Shell
Date: Sun, 15 Oct 2000 22:03:17 GMT
I am trying to write a program that will wait for a client connect and then
launch (i.e., fork() + execve()) a shell (i.e., /bin/sh) and allow the
remote client to execute commands in that shell. I realize that's not very
secure and may seem like I'm trying to write a back door, but trust me, it's
really just an learning experiment in Linux system programming.
I understand that I need to redirect stdout, stderr, and stdin in the child
process to a pipe via dup2() and read from and write to that pipe in the
parent, sending stdout/stderr data to the client and sending data from the
client to stdin.
I have most of it working. But, I seem to be have a problem with either the
data being buffered on either end or the process blocking while waiting for
data on a file descriptor.
Can anyone tell me the right way to do this? Am I headed in the right
direction? Or is their a sample of this anywhere?
Thanks for your help.
Steve Wamsley
[EMAIL PROTECTED]
------------------------------
Crossposted-To: comp.os.linux.misc,comp.os.linux.hardware
Subject: Re: LILO version 21.6 released
From: Rudi Sluijtman <[EMAIL PROTECTED]>
Date: Sun, 15 Oct 2000 22:05:47 GMT
Hi John,
John in SD <[EMAIL PROTECTED]> writes:
> >John in SD <[EMAIL PROTECTED]> writes:
> >> LILO release 21.6 is based upon Werner Almesberger's LILO version 21.
> >
> >Could you please provide us with, or point to, some documentation about
> >the usage of the "- Completely new menu-driven user interface."
>
> Usage information on what keys to press is contained in the menu itself.
> Customization information is provided in the 'man' pages for 'lilo.conf'.
In the man pages for lilo.conf I only find:
message=message-file
specifies a file containing a message that is dis�
played before the boot prompt. No message is dis�
played while waiting for a shifting key after
printing "LILO ". In the message, the FF character
([Ctrl L]) clears the local screen. The size of the
message file is limited to 65535 bytes. The map
file has to be rebuilt if the message file is
changed or moved.
How can I use this for a graphical boot-menu like RedHat does in rh7?
What do I miss?
thx,
Rudi Sluijtman.
------------------------------
From: Todd Knarr <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.admin,comp.os.linux.networking,comp.os.linux.setup
Subject: Re: A new directory hierarchy standard - need opinions
Date: 15 Oct 2000 23:39:11 GMT
In comp.os.linux.development.system <[EMAIL PROTECTED]>
[EMAIL PROTECTED] wrote:
> When a package has more than a few executeables, or any libraries or
> data it needs to access, I prefer having the whole package "encapsulated"
> where I can see where it is, how much space it all takes, remove it all
> if I want, or tarball it to another machine to run it there.
For viewing, that's what I consider package-management to be for: hold
all the details on the files in a package no matter where they are on the
machine. Integrating packages into the regular system also forces me to
deal with things like library-name conflicts up-front, not later on when
someone finally decides to use the wrong combination of packages at the
same time and something blows up.
> The disadvantage is that a package may need to have some files shared
> between many machines and some files separate per machine. Perhaps
> the best solution would be /usr/opt and /var/opt. Those can either or
> both be mounted as distinct filesystems as desired.
I usually like /var/{package}, much like /etc/{package} for configuration.
Why add another level to that directory tree for the same purpose unless
you need to to avoid name conflicts? Same with /etc. I look at it as being
that /var and /etc are where files that'll need to be modified by the
admins go, or where configuration files go, regardless of package. The
/|/usr|/usr/local division is for stuff related to package management
issues and whether something's needed during start-up, not writeability
or access.
> Maybe. See above for /var/opt. But I'll extrapolate into /usr/local/opt.
> I usually leave /usr mounted read-only and /usr/local mounted writeable.
For normal things, read-only mounting doesn't matter because nobody but
root should have write access even to /usr/local, let alone /usr ( modulo
a few exceptions handled via SUID/SGID and proper ownerships ). Any work
on packages like you describe I do under a regular user, working under
their own home directory, _then_ port it to system directories when it's
done via a regular install to confirm that it works right. Keeps down the
chance of hosing something and forces me to deal with locations and
permissions without depending on root-specific things.
--
If it's a hobby for me and a job for you, why are you doing such a shoddy
job of it?
-- Linus Torvalds
------------------------------
** 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
******************************
