Linux-Development-Sys Digest #701, Volume #6 Tue, 11 May 99 15:14:36 EDT
Contents:
Re: RPC Brokers (J.H.M. Dassen (Ray))
Re: NFS-Server setup (Zoran Cutura)
Re: Reliable (!) nic for 2.2 kernel? ([EMAIL PROTECTED])
Re: what means cli() and sti()? (Keith Wright)
Re: /dev/hda1 has reached maximal mount count, check forced (Emile van bergen)
Re: Couple of questions (Paul Kimoto)
Re: listing symbols in a dynamic library (John Reiser)
Re: RedHat 5.2 "control-panel" eating resources? (Denice)
Problem with Kernel 2.2.5 and Regal CD-Changer (Henning Sauer)
Re: Trouble passing TCP packets through Raw Socket (Andi Kleen)
Re: NFS-Server setup ("Bernat Ginard Lladó")
struct iso9660 problem ("Thierry BUCCO")
Re: Translation of linux to minor languages (Guest)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (J.H.M. Dassen (Ray))
Subject: Re: RPC Brokers
Date: 11 May 1999 07:43:26 GMT
Thomas J. Clancy <[EMAIL PROTECTED]> wrote:
>I was wondering if there is a product out there for Linux that is similar
>to Inprise's Entera product. We currently use the Entera RPC broker on an
>HP-UX box, but we're considering creating a cluster of Linux boxes and
>porting our server software to it. But, we need an RPC broker.
Could you explain a bit more what you mean by an "RPC broker"? Linux has
regular RPC support, and distributed computing support via standards like
CORBA (http://linas.org/linux/corba.html).
Ray
--
ART A friend of mine in Tulsa, Okla., when I was about eleven years old.
I'd be interested to hear from him. There are so many pseudos around taking
his name in vain.
- The Hipcrime Vocab by Chad C. Mulligan
------------------------------
From: Zoran Cutura <[EMAIL PROTECTED]>
Subject: Re: NFS-Server setup
Date: Tue, 11 May 1999 11:16:07 +0200
Alfred Glass wrote:
>
...snip...
>
> Sorry Bernat,
> the "rpc.nfsd" gives me the same answer like the "rpc.mountd".
>
> Additional Info.: The Server is my small Linux-Target-Computer. For NFS I
> have copied the "rpc.mountd, rpc.nfsd, and portmap" files to the target.
> But only "portmap" will start. That´s my Problem.
>
> Has anyone else an Idea what I can do ??
> or which files or libraries are necessary for NFS ??
>
> Alfred....
Hello Alfred,
The message you get indicates that the portmap deamon is not running!
You can check weather it is by typing 'rpcinfo -p' this should give a
all rpc-services available on your local host!
If there is no such service as rpcbind the portmap-deamon is not
running!
Try to start portmap with -d and/or -v option to see debug infos.
Bye
Zoran
--
LISP is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days. Eric S. Raymond
========================================================================
_/_/_/_/_/ _/_/_/_/ from: Zoran Cutura,
_/ _/ _/ IMH-Innovative Motorentechnik Prof. Huber,
_/ _/ post: DaimlerChrysler AG, EP/VES, T900,
_/ _/ 70546 Stuttgart, Germany,
_/ _/ phone: +49711 17-42353
_/ _/ _/ mobil: +49171 4488407
_/_/_/_/_/ _/_/_/_/ email: [EMAIL PROTECTED]
PGP fingerprint: F0 C3 30 F4 B3 7E 22 36 1C 51 B7 60 A9 BB 23 BE
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking
Subject: Re: Reliable (!) nic for 2.2 kernel?
Date: 11 May 1999 02:24:33 GMT
In article <0EXY2.11020$[EMAIL PROTECTED]>,
bryan <[EMAIL PROTECTED]> wrote:
>my tulip card is totally unreliable. I can bring it down with an ftp
>xfer (local lan) at 10 or 100, in a minute or less. network hangs and
>will NOT be reset by software.
Do you get a message in /var/log/messages when it gives up the ghost?
It's possible that a kernel oops in the driver's interrupt handler (or even in
another interrupt handler shared on the same IRQ with your tulip) is causing
the interrupt to be disabled, leaving you off-the-air. You should get log
messages when this sort of thing happens.
Other suggestions: try setting tulip_debug, or E-mailing the author of the
driver. If it's really a driver problem, he'll want to know about it.
Regards,
Graham
------------------------------
From: Keith Wright <[EMAIL PROTECTED]>
Subject: Re: what means cli() and sti()?
Date: 10 May 1999 23:58:04 -0400
lckun <[EMAIL PROTECTED]> writes:
> What means the functions cli() and sti() in the source sched.c of
> kernel?
Clear Interupt Flag and Set Interupt Flag. (Disable interupt handling
for the duration of a critical section.
> Please tell me what it means and where can i find the more infomation
> for this functions...
Intel Pentium processor reference. (These are machine code instructions
manifested as C.)
--
-- Keith Wright <[EMAIL PROTECTED]>
Programmer in Chief, Free Computer Shop <http://www.free-comp-shop.com>
--- Food, Shelter, Source code. ---
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware
Subject: Re: /dev/hda1 has reached maximal mount count, check forced
Date: Thu, 6 May 1999 08:08:49 +0200
On 5 May 1999, bill davidsen wrote:
[SNIP]
>Sure would like to disable the mount count with a lilo option or some
>such, there are times when I need a system up *now* not after the time
>it takes to frolic through 40GB of RAID storage.
Uhm... Did you remember that all kernel parameters (passed to it by
Lilo) which the kernel doesn't understand itself, are passed as
environment to 'init' and then onwards to the scripts (e.g.
/etc/rc2.d/s20mountlocal on my system)...? Guess you could figure out
the rest yourself... ;-)
Also, the kernel commandline is in /proc/cmdline, if for some reason
there's an env - somewhere.
Hope this is of some help.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: Couple of questions
Date: 11 May 1999 00:59:51 -0500
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>, Kal Kolberg wrote:
> I have an oops in the log file, how do I track this down.
Please read Documentation/oops-tracing.txt
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (John Reiser)
Subject: Re: listing symbols in a dynamic library
Date: Tue, 11 May 1999 05:21:20 GMT
The return value from dlopen() is really a struct link_map * ; see
<link.h>. The member link_map.l_addr is really a Elf_32Ehdr * ; see
<elf.h>. Some hints can be found in the sources of /usr/bin/objdump,
the BFD library, and glibc-2.0.7/elf/{dl-*, rtld.c} . Apply liberal
doses of sessions with gdb, objdump, and od .
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
------------------------------
Subject: Re: RedHat 5.2 "control-panel" eating resources?
From: Denice <[EMAIL PROTECTED]>
Date: 11 May 1999 18:24:24 +0100
[EMAIL PROTECTED] (Dr H. T. Leung) writes:
>I have a RedHat 5.2 box (plus a Slackware 3.6) and I just discovered that the
>process "control-panel" is eating up 50% of the CPU usage (the other 50% is a big
>micromagnetic simulation I am running - on the Slakware box, normally I get about
>97% users when most of the other, including X windows, are idle), as "top" shows.
>Okay, I shouldn't have left things I don't need running. But
>Why is it eating resources? I thought it is simply a glorified config-file
>editor, installation database searcher, among other things; for it to be idle, it
>shouldn't be eating CPU cycles, right?
This usually means that control-panel didn't die as it *should* when you log
out (usually from a root login at the console on redhat 5.x systems).
Instead it is inherited by init, and consumes lots of CPU cycles in
this state (and is of course perfectly useless). Some other X-culprits do
this too on occasion (eg: netscape). Check if init owns the process
(PPID = 1), then kill it:
eg:
$ ps -aulx
output is (editted to fit on one line):
FL UID PID PPID PRI NI SIZE RSS WCHAN STA TTY TIME COMMAND
100 0 30151 1 19 0 2428 1516 R ? 7:12 control-panel ...
------------------------------
From: Henning Sauer <[EMAIL PROTECTED]>
Subject: Problem with Kernel 2.2.5 and Regal CD-Changer
Date: 06 May 1999 20:50:59 +0200
Hello,
I just upgraded from RedHat 5.2/i386 (Kernel 2.0.36) to RedHat 6.0/i386
(Kernel 2.2.5) and now I can only boot when my Regal SCSI CD changer is
switched of, or I have not compiled it with "probe all LUN´s". If I try
to boot it with "probe all LUN´s" and the Regal CD changer is switched
on, it stops when the NCR8xx driver recognizes the Regal CD Changer.
With 2.0.36 I did not have this problem.
What can I do to get my CD changer working with 2.2.x ?
Bye,
Henning
------------------------------
Subject: Re: Trouble passing TCP packets through Raw Socket
From: Andi Kleen <[EMAIL PROTECTED]>
Date: 11 May 1999 19:40:36 +0200
Dave Koogler <[EMAIL PROTECTED]> writes:
> I am writing an user-level application for routing IP packets from
> an HDLC serial interface through a Linux system. I receive packets
> from the serial interface and pass them to the Linux system via a
> set of three raw sockets: one for ICMP, another for UDP, and a third
> for TCP. Each socket operates with the IP_HDRINCL option, which allows
> me to pass the IP header along with the rest of the packet.
First this looks hackish. For general purpose packet insertion
you would probably use a SOCK_PACKET socket though (which operates at layer2
only), instead of doing all that special purpose code. You would inject
it to a dummy interface.
Linux 2.2 also has a special purpose device for this application: ethertap.
>
> ICMP and UDP messages work fine. TCP messages fail, but in a rather
> unusual way. It appears that the raw socket passes the IP and TCP
> headers, but with the IP total length set as just the size of the
> two headers without the data. But the incoming packet does have data.
Does this happen on sending or receiving?
Could you post a small test program for that? (that would clear the
ambiguities)
Does 2.2 show the same thing?
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: "Bernat Ginard Lladó" <[EMAIL PROTECTED]>
Subject: Re: NFS-Server setup
Date: Mon, 10 May 1999 20:09:00 +0100
Alfred Glass wrote:
> I want to setup a small RedHat-Linux-System (RH5.1) as NFS-server for
> software developement. So I looked into the NFS-HOWTO.
>
> First I have configured TCP/IP. The "ping" works.
> Then I wrote the "/etc/exports" - file.
> Then I have started the "portmap" daemon. I checked this with "ps aux" .
> In the next step I have startet "rpc.mountd". Now I got the following answer
> :
And the rpc.nfsd?
Start it too, and it will work fine.
--
_______________________________________________________
Bernat Ginard Lladó
mailto:[EMAIL PROTECTED]
------------------------------
From: "Thierry BUCCO" <[EMAIL PROTECTED]>
Subject: struct iso9660 problem
Date: Tue, 11 May 1999 11:57:04 +0200
Hi,
I have a little problem,
i want to retrieve info about iso9660 cdrom.
here is my code :
struct iso_primary_descriptor iso9660;
FILE *fd;
fd=fopen("/dev/cdrom","r");
fread(&iso9660, sizeof(struct iso_primary_descriptor),1,fd);
fclose(fd);
printf("\n-> Publisher ID : %s",iso9660.publisher_id);
but doesn't works why ?
Thanks a lot for your help.
Thierry BUCCO
- FRANCE -
------------------------------
Date: Tue, 11 May 1999 11:59:22 +0200
From: [EMAIL PROTECTED] (Guest)
Subject: Re: Translation of linux to minor languages
> > - dialog resizing is required and takes over 60% of the actual work,
> > provided you have a good WYSIWYG tool to help you. (the suggestion to use
> > strings, which are no longer then the EN string doesn't work, don't even
> > consider it).
>
> Use the layout manager widgets, they are you friend. If you used layout
> manager widget's then length of you text strings is not important anymore.
First of all, I would like to say that I don't know the current state of
developments on Linux & localization, so the stuff stated below may be already
implemented or rejected for some reason, but because I do have some experience
in creating localized GUIs (actually I created a GUI library which allowed
the GUI programmers to create localized GUIs in a simple way), I wanted to
comment on the topic.
I agree that widgets are the way to go, but they also make it a lot harder to
create a 'sexy' GUI because you're never 100% sure how the widgets will be
layed out. This is a general problem with localized GUI's: they may look
great in one language and extremely ugly in another. That's why sometimes it
is more appropriate to have a per-language implementation of each dialog and
once you choose that method, a simple WYSIWYG tool will be faster than
programming code (or a more complex layout tool) with widgets.
> > - text pieces, which are combined at runtime are a nightmare: "The xxxx
> > could not be xxxx, because xxxx" can not be translated, because you are
> > combining e.g. Russian text fragments using English grammar.
>
> This is usually bad practice anyway
But sometimes you can't avoid it. A simple example are numbers: if some
program needs to display a status message (so a single string) like: 'There
are xx unread mails', then the code doing this will probably do something
like:
String formatString = LOC_Lookup("There are %d unread mails");
String actualString = Format(formatString,nrUnread);
Where the Format function is a kind of sprintf wrapper. This works well with
one parameter, but once more parameters are needed, the problem that some
translations will need them in a different order pops up. On SGI/IRIX the
sprintf implemented a notation like '%2$d' to indicate that the second
parameter should be used here, which allowed shuffling the parameters around
in foreign languages, but since this isn't ANSI, I doubt it's available on
Linux.
> > - How do you translate directory and file names? You don't? Well, what if
> > they appear in the UI?
You don't have to translate them. In our case the program simply used the
system default encoding (which could be anything from Latin-1 to SJIS or
BIG5). This means that all the strings were still represented as char *, but
were actually multi-byte strings. Since X also used the system default
encoding, this allowed us to simply translate the Latin-1 strings into SJIS
without the programmer ever needing to know about it (he does have to realize
however that the size of an object is not fixed).
Now, if we had to do it over again, we'd probably use UTF-8 as encoding
instead of all the different per-country and per-language encodings like SJIS
and BIG5. I think that's also the way Linux is going: since UTF-8 only uses
characters above 127 for its multibyte stuff, it won't conflict with special
characters like '/' in filenames, so you could allow the user to simply use
UTF-8 for his filenames. The only two parts of the system which really need
to know about this are probably the in- and output, i.e. the input-method to
allow the user to type special foreign characters (read Japanese) on a
keyboard that only has a limited number of keys and the visualization,
i.e. the widget-set or whatever you want to use (so: GTK or that library used
by KDE).
> Why should they appear in the UI?
Oh come on ... Never heard of a file-selector or an error message stating this
or that file was locked or unreadable or corrupt ...
> > - does passwd accepts Japanese or cyrillic characters (or simply say latin
> > characters, which are not used in English) as password and/or login name?
> > Ooops, that means cyrillic and Japanese directory names in /home. Can "ls"
> > deal with them? And can they be found by e.g. a "find -name"?
Again using UTF-8 would solve part of this without needing to change the
file-system. The only problem with ls would be that it would probably get the
column-width wrong when using multi-columns or ls -l. The reason being that
without modifications ls would assume a multibyte UTF-8 encoded string
containing 1 character of 3 bytes to be 3 characters wide. It would be nice
if strlen could be adapted to handle this, but this would break programs that
use strlen to determine how much memory to allocate for a copy of a string or
how many bytes should be written to disk. So, I guess some kind of
UTF8strlen() function should be available and ls and other tools that really
need to know the width of a string in characters should use that instead.
And to answer your question: yes, passwords could be UTF-8, since the program
wouldn't really see the difference between a UTF-8 encoded char * or one using
some other (read Latin-1) encoding. The problem would lie with some
input-method allowing the user to type such a password. The system therefor
would have to be modified so that all characters that are typed are passed
through the input-method. On the other hand, programs like games probably
want direct access to the keyboard, i.e. they're not interested in the meaning
of key-sequences, but just want to know which keys are pressed. I don't
really know how passwd (or the login prompt) gets its input, but I don't think
it needs direct access to the keyboard, so passing it through an input-method
should be possible. I'm not a kernel hacker though ...
> As your user name does not have to represent your real name this is not
> important. Why should passwd need to accept Japanese or cyrillic characters?
To have a Japanese password perhaps.
> > And for UNIX you have the additional problem that the output of command line
> > commands is often used as the input for the next command in a pipe. So if
> > you translate the output of let's say "ls", then you have to re-engineer all
> > programs, which possibly read the output of ls and take it as their input.
This isn't a real problem. Programs or scripts requiring output in a specific
language should take care of the problem by setting the localization (the LANG
variable ?) to the correct value.
> I can see that a user might want to use non latin characters in a file name,
> but I don't think that ext2 supports Unicode file names, so this is a
> moot point currently. It will however take a massive effort to get
> working.
No it won't. ext2 just sees byte-sequences terminated by a NUL-byte. How
these sequences are interpreted (except for the '/' separator) is up to the
programs using them. I can use Japanese filenames on my 2.0.36 based Linux,
but in order to actually see them as Japanese, I would need a program turning
the UTF-8 encoding I use for the filenames into the appropriate glyphs on the
screen. That step (and the one to enter such strings) should become part of
the OS (or the libraries) instead of requiring each program to make its own
implementation. Components without direct user-interaction (so no
visualization and no user entering data directly into it) will not need to
know that UTF-8 is used, since they couldn't care less whether those 3 bytes
represent 3 Latin-1 characters or 1 foreign character.
------------------------------
** 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
******************************
