Linux-Development-Sys Digest #768, Volume #8 Sun, 3 Jun 01 00:13:12 EDT
Contents:
flush() system call?? ("wangyin")
flush() system call?? ("wangyin")
flush() system call? ("wangyin")
Re: flush() system call? (Juergen Heinzl)
modemAPI.h ??? (No Name)
Re: environment variable confusion ([EMAIL PROTECTED])
reading & writing memory & ports
Re: reading & writing memory & ports ("Karl Heyes")
Re: reading & writing memory & ports
Re: fast disk writes (Kai Henningsen)
[solved] Re: wchar_t and Unicode (Michael B. Allen)
Re: Linux IO scalability (Paul Repacholi)
----------------------------------------------------------------------------
From: "wangyin" <[EMAIL PROTECTED]>
Subject: flush() system call??
Date: Sat, 2 Jun 2001 13:49:52 +0800
I've seen "flush" in file_operations structure. But there isn't a flush()
system call in Linux. What's this entry for?
------------------------------
From: "wangyin" <[EMAIL PROTECTED]>
Subject: flush() system call??
Date: Sat, 2 Jun 2001 13:47:05 +0800
I've seen "flush" in file_operations structure. But there isn't a flush()
system call in Linux. What's this entry for?
------------------------------
From: "wangyin" <[EMAIL PROTECTED]>
Subject: flush() system call?
Date: Sat, 2 Jun 2001 14:05:40 +0800
I see there is a "flush" in file_operations, but there seems not a flush()
system call in Linux. What's this entry for?
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: flush() system call?
Date: Sat, 02 Jun 2001 21:00:40 GMT
In article <9f9vg6$278o$[EMAIL PROTECTED]>, wangyin wrote:
>I see there is a "flush" in file_operations, but there seems not a flush()
>system call in Linux. What's this entry for?
[-]
fflush() is not a system call, it's part of stdio. See fflush(3) for
what it is for,
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: No Name <[EMAIL PROTECTED]>
Subject: modemAPI.h ???
Date: Sat, 2 Jun 2001 21:27:37 +0100
Reply-To: [EMAIL PROTECTED]
All,
I am trying to compile some code and I need a header file called
modemAPI.h
It looks like it should be found in a development rpm package, but I
cannot find the correct one.
Does anyone know where this file is located?
I am running Linux RedHat 6.2
Any help appreciated.
Regards
Nick
--
Nick Thomas
Email: [EMAIL PROTECTED](Removezz)
WWW: http://www.nhthomas.freeserve.co.uk
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: environment variable confusion
Date: 2 Jun 2001 15:28:24 -0700
In article <[EMAIL PROTECTED]>,
Eric Taylor <[EMAIL PROTECTED]> wrote:
>Wow, thanks for all the details, I think I see
>what is going on now , and I have only
>one more question (but first some explanation):
>
>----------------------------
>When I grow the environment, the saved stack area gets
>restored in the same place it was, but that now
>overlaps the pointers to the env variables since
>adding the large env variable results in everything
>starting at a lower address. So, the env vector
>gets clobbered on my (only partial) stack restore.
>
>I think you are correct that the entire top of
>the stack should be saved/restored. But if I do
>that, I think I would have to see that environ
>got restored as well and I don't know how to
>do that for the libc .so library.
>
>It was mentioned that if environ is in the bss
>area, then even the .so libraries would use that.
>otherwise they would use their own copy. I found
>some source code that seems to indicate that
>this might not happen
I have tried a simple program that dynamically loads a library, which
in turn, prints the address of environ and some selected entry. This
works correctly whether or not the original program mentions environ.
This library output indicates that both environ and __environ are in
the program bss-area if it contains a reference to environ. I have
included the two programs below.
I believe that you could simply add a dummy reference to environ
somewhere in your program and get it restored automatically with the
rest of your data.
>I found this definition in environ.c, but don't undestand
>the comment:
>--------
>/* This must be initialized; we cannot have a weak alias into bss. */
>char **__environ = NULL;
>weak_alias (__environ, environ)
>-----------
>
>
>I stepped getenv thru with gdb. I found
>the address of environ, in one of the rw sections of
>libc .so dyn library. So, as mentioned, this must
>be a dynamic environ and not in my bss area.
>
>I think my difficulty is that I don't understand how
>weak or weak_alias is implemented.
I don't know the details, and the documentation doesn't say anything
about it, but the idea is essentially as follows. A library variable
or function is provided with the "weak" attribute. If the user code
doesn't provide one with the same name, the library version is linked.
If the user does provide one, the library version is ignored.
>So, the (final?) question is how does the loader know what value
>to initialize this dynamic environ to? The correct value seems to be an
>attribute of the new process that exec has just setup. But
>it's not until a bit later that libc is loaded and that is when
>environ comes into existance for libc.So the true value for
>environ must be saved somewhere (in the kernel?) while
>exec is setting up the environment. Or do I have the order
>of this backwards?
My guess is that ld-linux.so.2 does this. The exec() loading sequence
first loads the user program, and then the "elf-interpreter." Control
actually passes to the interpreter, which finally finds its way to the
user program entry point via one of the elf-parameters on the stack.
The interpreter loads and links libc et. al., and I would guess sees
that the user program has an "environ" variable and links that into
the various places that need it, including the references within libc.
If you look for "V" entries in an nm listing of libc, you will find
about fifteen other symbols like this. The idea here is that libraries
can link to external symbols in other libraries, or even the user
program. The weak definition is simply a fall-back when no external
match is found.
>Thanks again, as usual the help in this message board
>is fabulous!!
>
>
>
>
>--------------------------------------------------
>Here is what I have been looking at. If there are any
>assembler experts out there, maybe someone can
>explain how this reference to __environ works.
>
>
>
>
>Here is the beginning of getenv.c
>---------------------------
>#ifndef HAVE_GNU_LD
>#define __environ environ
>#endif
>
>char *
>getenv (name)
> const char *name;
>{
> size_t len = strlen (name);
> char **ep;
> uint16_t name_start;
>
> if (__environ == NULL || name[0] == '\0')
> return NULL;
>---------------------------------
>
>Here is it disassembled, I can't figure out what
>that call to qsort+336 is all about and the use of
>ebx. Could that be how environ gets set up?
I think that the "qsort" reference is bogus. The sorted list of symbols
for my particular libc.so.6 (2.2.3, built here) shows this:
0002f150 t _quicksort
0002f5de t Letext
0002f5e0 t msort_with_tmp
0002f77c T qsort
0002f89b t Letext
0002f8a0 T getenv
0002f9b8 t Letext
0002f9c0 T putenv
0002fa45 t Letext
0002fa50 t __add_to_environ
0003002c W setenv
0003002c t __setenv
0003005c W unsetenv
0003005c t __unsetenv
00030174 W clearenv
00030174 t __clearenv
000301fc t free_mem
Perhaps the compiler put a very short internal subroutine _before_ the
entry to getenv().
>
>-----------------------------
>Dump of assembler code for function getenv:
>0xa006fcd4 <getenv>: push %ebp
>0xa006fcd5 <getenv+1>: mov %esp,%ebp
>0xa006fcd7 <getenv+3>: push %edi
>0xa006fcd8 <getenv+4>: push %esi
>0xa006fcd9 <getenv+5>: push %ebx
>0xa006fcda <getenv+6>: sub $0xc,%esp
>
> (this next part I don't understand)
>
>0xa006fcdd <getenv+9>: call 0xa006fcd0 <qsort+336>
>0xa006fce2 <getenv+14>: add $0xf516a,%ebx
>
>(I think this is the strlen)
>
>0xa006fce8 <getenv+20>: mov 0x8(%ebp),%eax
>0xa006fceb <getenv+23>: mov (%eax),%dl
>0xa006fced <getenv+25>: lea 0x1(%eax),%eax
>0xa006fcf0 <getenv+28>: test %dl,%dl
>0xa006fcf2 <getenv+30>: jne 0xa006fceb <getenv+23>
>(end of strlen)
>
>
>0xa006fcf4 <getenv+32>: mov 0x8(%ebp),%edx
>0xa006fcf7 <getenv+35>: sub %edx,%eax
>0xa006fcf9 <getenv+37>: dec %eax
>0xa006fcfa <getenv+38>: mov %eax,0xfffffff0(%ebp)
>
>(is this -below- the check for __environ == NULL)
>
>0xa006fcfd <getenv+41>: mov 0x884(%ebx),%eax
>0xa006fd03 <getenv+47>: mov (%eax),%edx
>0xa006fd05 <getenv+49>: test %edx,%edx
>0xa006fd07 <getenv+51>: je 0xa006fd58 <getenv+132>
>
>(this -below- looks like the check for name[0]==0)
>
>0xa006fd09 <getenv+53>: mov 0x8(%ebp),%ecx
>0xa006fd0c <getenv+56>: cmpb $0x0,(%ecx)
>0xa006fd0f <getenv+59>: je 0xa006fd58 <getenv+132>
>
>
>(Here is that call to setup ebx:)
>
>0xa006fcd0 <qsort+336>: mov (%esp,1),%ebx
>0xa006fcd3 <qsort+339>: ret
This, of course, is where the qsort+336 address comes from. I guess
gdb doesn't like to print "symbol-number" addresses.
The following are the test program and library. The program version
is obviously the one that references environ. Removing the environ
declaration and dummy reference near the end creates the other version.
envdl-ref.c:
===================================================================
#include <stdio.h>
#include <dlfcn.h>
main(int argc, char **argv)
{
extern char **environ;
void *dlib;
void (*env2)();
char *str;
int n;
if (argc != 2) {
fprintf(stderr, "usage envdl number\n");
exit(1);
}
n = strtol(argv[1], (char **)0, 10);
if ((dlib = dlopen("/tmp/libenv.so", RTLD_NOW)) == NULL) {
perror("dlopen");
exit(1);
}
str = dlerror();
if (str) {
fprintf(stderr, "%s\n", str);
exit(1);
}
if ((env2 = dlsym(dlib, "env2")) == NULL) {
perror("dlsym");
exit(1);
}
str = dlerror();
if (str) {
fprintf(stderr, "%s\n", str);
exit(1);
}
printf("env2: %08x\n", env2);
env2(n, environ);
sleep(15);
return 0;
}
===================================================================
This is the "library".
env2.c:
===================================================================
#include <stdio.h>
void
env2(int n)
{
extern char **environ;
extern char **__environ;
printf("At env2(%d)\n", n);
fprintf(stdout, "&environ: %08x\n", &environ);
fprintf(stdout, "environ: %08x\n", environ);
fprintf(stdout, "&__environ: %08x\n", &__environ);
fprintf(stdout, "__environ: %08x\n", __environ);
fprintf(stdout, "*environ: %08x\n", *environ);
fprintf(stdout, "*environ: %08x\n", environ[0]);
fprintf(stdout, "*environ: %08x\n", environ[n]);
fprintf(stdout, ">> %s\n", environ[n]);
return;
}
===================================================================
This stuff was built with:
gcc -g -o envdl-ref{,.c} -ldl
gcc -g -o envdl-noref{,.c} -ldl
gcc -g -fPIC -c env2.c
gcc -g -shared -o libenv.so -Wl,--soname=libenv env2.o
And executed in /tmp with:
LD_LIBRARY_PATH=/tmp envdl-ref 7 &
The "7" selected some random env entry and the backgrounding was to
allow display of the /proc/../maps entry.
--
B. D. Elliott [EMAIL PROTECTED]
------------------------------
From: <[EMAIL PROTECTED]>
Subject: reading & writing memory & ports
Date: Sat, 2 Jun 2001 16:38:21 -0700
Well, I guess I am still struggling a bit in trying to find a utility
within Linux at allows me to read and write to hardware addresses as I work
on an embedded project. I can get part way to where I need to be with setpci
for PCI configuration space, and I can see PCI config space with
'lspci -xx'. The utility 'lsdev' is somewhat useful also. What I really need
is a utility that allready exists in the kernel that will allow the reading
and writing of absolute memory space and absolute I/O port space. I can get
part way there with /dev/port, but not all the way.
What I really need is basically gdb unleashed. Maybe gdb can do what I
need, but I just dont have enough knowledge to use it. In the case of gdb, I
can open it, define a mem space, but when I issue the 'x' command, gdb tells
me that I cannot access that memory (all of this is as root, and again, this
is an embedded system, not a multiuser server so security issues don't
apply).
Can someone tell me how I might either get gdb to access arbitrary
memory or point me at another utility within the Linux distribution that
would allow me to query and set memory and I/O port space for the underlying
hardware?
Charles
------------------------------
From: "Karl Heyes" <[EMAIL PROTECTED]>
Subject: Re: reading & writing memory & ports
Date: Sun, 03 Jun 2001 01:38:25 +0100
In article <RLeS6.1715$[EMAIL PROTECTED]>, "Unknown"
<[EMAIL PROTECTED]> wrote:
> Well, I guess I am still struggling a bit in trying to find a utility within
> Linux at allows me to read and write to hardware addresses as I work on an
> embedded project. I can get part way to where I need to be with setpci for
> PCI configuration space, and I can see PCI config space with 'lspci -xx'.
> The utility 'lsdev' is somewhat useful also. What I really need is a utility
> that allready exists in the kernel that will allow the reading and writing
> of absolute memory space and absolute I/O port space. I can get part way
> there with /dev/port, but not all the way.
how about opening /dev/mem and seeking to the address you want. It sounds
like you been accessing virtual not physical memory.
karl.
------------------------------
From: <[EMAIL PROTECTED]>
Subject: Re: reading & writing memory & ports
Date: Sat, 2 Jun 2001 18:15:01 -0700
Well, I am trying to find a utility usuable from a shell. So, thanks to
someone else here, I have tried 'dd if=/dev/port bs=1 count=1 skip=1016' and
this does return a byte from port 0x3F8, but the byte is not displayed as
the hex value, but rather as ascii, meaning a byte of value 0x30 will show
up as an '0', 0x31 as a '1' an so forth. If I knew how to tell the shell how
to easily change 0x31 and display '31', that might help, but this is still a
very cumbersome way to have a way to read an IO port. I have to believe that
either gdb can do it and I just don't know the magic incantation for gdb or
there is some other useful utility.
"Karl Heyes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> In article <RLeS6.1715$[EMAIL PROTECTED]>, "Unknown"
> <[EMAIL PROTECTED]> wrote:
>
>
> > Well, I guess I am still struggling a bit in trying to find a utility
within
> > Linux at allows me to read and write to hardware addresses as I work on
an
> > embedded project. I can get part way to where I need to be with setpci
for
> > PCI configuration space, and I can see PCI config space with
'lspci -xx'.
> > The utility 'lsdev' is somewhat useful also. What I really need is a
utility
> > that allready exists in the kernel that will allow the reading and
writing
> > of absolute memory space and absolute I/O port space. I can get part way
> > there with /dev/port, but not all the way.
>
> how about opening /dev/mem and seeking to the address you want. It sounds
> like you been accessing virtual not physical memory.
>
> karl.
>
------------------------------
Date: 03 Jun 2001 00:54:00 +0200
From: kaih=82B$[EMAIL PROTECTED] (Kai Henningsen)
Subject: Re: fast disk writes
r@cLIeNUX. (cLIeNUX user) wrote on 30.05.01 in <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED]
> >In article <[EMAIL PROTECTED]>,
> >cLIeNUX user <r@cLIeNUX.> wrote:
> >
> >>I thought Linux' first filesystem was Minix, and Remy Card wrote ext2 ON a
> >>Minix filesystem?
> >
> >Minix filesystem is a toy version of v7 fs with block bitmap added in the
> >beginning of the disk. Ext2 consists of cylinder groups, each with its own
>
> A block bitmap. That's a rather striking family trait, don't you think?
If it were, you'd be in trouble, as Apple DOS also had a block bitmap
(with block size = sector size = 256 bytes, on a 140KB floppy).
*And* indirect blocks and 30-character filenames. But no subdirectories
and no inodes.
> >fragment of inode and block bitmaps and inode table - the main improvement
> >introduced by FFS. Directory layout is straight from FFS, except for the
> >odd
>
> "the main improvement introduced by FFS" being cylinder groups, yes?
That was also the main thing HPFS coipied from FFS. Maybe also NTFS? At
least NTFS can support POSIX semantics[0] (though it doesn't much like
them[1], and without symlinks).
[0] Necessary for their toy POSIX subsystem.
[1] Getting Win32 to create a link is ... interesting. But possible (see,
for example, cygwin). Case-sensitive filenames are somewhat easier, though
you still need to study the docs closely to find out how.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (Michael B. Allen)
Subject: [solved] Re: wchar_t and Unicode
Date: 3 Jun 2001 03:08:23 GMT
Reply-To: [EMAIL PROTECTED]
Michael B. Allen wrote:
>I am writing an app that must do network I/O with quite a bit of UCS-2LE
>encoded strings in it. I can see wchar_t doesn't like to be converted to
>or constructed from the various Unicode encodings. What type of encoding
>it wchar_t anyway? I take it I must write my own sting handling functions
>for this! :~(
>
>Why doesn't wchar_t play nice with Unicode encodings and how do I get
>around this problem?
I found out from the linux-utf8 mailing list that if the C99
__STDC_ISO_10646__ macro is defined then the wchar_t type are USC codes
such that the following is possible for converting from UCS-2 to whcar_t:
> uint16_t *p; /* UCS-2 input */
> wchar_t *q; /* wchar_t output */
>
> #ifdef __STDC_ISO_10646__
> /* Convert UCS-2 to wchar_t (typically UCS-4) */
> while ( *p )
> *p++ = *q++;
> #else
> /* Do nasty things with iconv() and mbstowcs */
> #endif
Mike
------------------------------
Subject: Re: Linux IO scalability
From: Paul Repacholi <[EMAIL PROTECTED]>
Date: 03 Jun 2001 11:32:15 +0800
"Shirish" <[EMAIL PROTECTED]> writes:
> Does Linux have an IO scalability issue. We here have 25 drives
> attached to a server with two fibre controller cards. The max
> thruput we can arrive at is around 40MB/s, thats like 5% PCI
> efficiency. If I have the same configuration under windows, I can
> easily do 250~300MB/s using the same HW configuration. Any clues!!
How fast can you CPU and memory move data? Kernel buffer remember.
NT at least can do direct IO.
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
Raw, Cooked or Well-done, it's all half baked.
Spam-To: [EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED],
[EMAIL PROTECTED],[EMAIL PROTECTED]
------------------------------
** 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
******************************
