Linux-Development-Sys Digest #972, Volume #7 Sat, 24 Jun 00 00:13:16 EDT
Contents:
Re: HELP, getting and changing network info (Chetan Ahuja)
Re: running remote untrusted code ([EMAIL PROTECTED])
Raid (MD not LVM) and 2.2.10->2.2.16 (Konstantinos Agouros)
nonblocking gethostbyname? (Damir Cosic)
Re: LILO Configuration Problem (John in SD)
xntpd not starting at boot (Brad Clawsie)
Re: function to get current year (tye4)
Re: function to get current year (Christopher Browne)
per process memory limit? (x86) (Paul Secinaro)
Lockup (Linux 2.2.16 + errata) while running "Terminus" demo ... (Chris Rankin)
Error code 105 (Craig Curtis)
----------------------------------------------------------------------------
From: Chetan Ahuja <[EMAIL PROTECTED]>
Subject: Re: HELP, getting and changing network info
Date: 23 Jun 2000 19:22:11 GMT
Robichaud, Jean-Philippe [BAN:6S33:EXCH] <[EMAIL PROTECTED]> spoke thusly:
> Hi ,
> How can I access to network information using ioctl. For now, all my
> try failed. Don't talk to me about ifconfig, I don't want to do a
> system() call and grep to have the ip address, netmask and so, I need to
> implement this functionnality (reading and hanging eth0, eth1, eth*...
> configuration) from a C program. Anyone knows about this ?
> Where can I find some example. I've have search the code of ifconfig
> without success.
> Please help !
> thanks
Well the obvious place to look would be the ifconfig source code then. No??
Chetan
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: running remote untrusted code
Date: Fri, 23 Jun 2000 19:27:21 GMT
Brennan Cheung <[EMAIL PROTECTED]> wrote:
> Yes. I knew Java could do it, but I want the code to run native. An
> interpreted language would be too slow. I am looking to run anywhere from
> 10,000 to 100,000 processes and so you can imagine that Java would be too
> slow.
Strictly speaking, java is a compiled language. It just happens that
it compiles to something most people pass through an
interpreter. Using, say, the java backend for gcc would compile it
down further.
A probably less painful idea is to just use custom objects, and
distribute a shared library for each platform, allowing bottlenecks to
be in C or assembler. This will quite probably be faster than C for
100k processes, as you can use something similar to the servlet
concept to avoid starting that many.
--
Matt Gauthier <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Konstantinos Agouros)
Subject: Raid (MD not LVM) and 2.2.10->2.2.16
Date: 23 Jun 2000 21:19:57 +0200
Hi,
I must have missed somehow what might have changed between 2.2.10 and 2.2.16.
There is no raidpatch for 2.2.16 so I suppose it should be included in 2.2.16.
I didn't change the config and it compiles. However when the 2.2.16 tries to
boot it doesn't find the root-device with a message like 'md0 not running'.
I added something like 'md0=0,-1,4,0,/dev/sda2' to the append-line in lilo.conf
like Documentation/md.txt says. Still no luck.
Anybody has a tip/clue for me?
Konstantin
--
Dipl-Inf. Konstantin Agouros aka Elwood Blues. Internet: [EMAIL PROTECTED]
Otkerstr. 28, 81547 Muenchen, Germany. Tel +49 89 69370185
============================================================================
"Captain, this ship will not sustain the forming of the cosmos." B'Elana Torres
------------------------------
From: Damir Cosic <[EMAIL PROTECTED]>
Subject: nonblocking gethostbyname?
Date: Fri, 23 Jun 2000 14:22:25 -0600
Is there any way (except having a process or thread just
for that) to get host by name in some kind of non blocking
or interruptable mode? What is gethostbyname() time-out and
can it be changed?
Thanks.
Damir
------------------------------
From: John in SD <[EMAIL PROTECTED]>
Subject: Re: LILO Configuration Problem
Reply-To: [EMAIL PROTECTED]
Date: Fri, 23 Jun 2000 20:51:15 GMT
'LIL' means the second stage loader received control; but it never completed.
It never tried to transfer control to the kernel.
1. What version of LILO are you running: 'lilo -V' will tell you.
2. What size disks do you have. (C:H:S geometry info), and how are they
partitioned. The output from 'fdisk / p' for each drive would be helpful.
3. Does you BIOS support EDD packet calls? The output from the diagnostic
floppy that comes with LILO 21.4.2 and later would be useful.
ftp://sd.dynhost.com/pub/linux/lilo has the source code and diagnostics.
--John Coffman
On Wed, 21 Jun 2000 04:56:39 GMT, [EMAIL PROTECTED] (Octalman) wrote:
>[Posted and mailed]
>
>In article <[EMAIL PROTECTED]>,
> "Jay Randall" <[EMAIL PROTECTED]> writes:
>> Hello,
>>
>> I am rebuilding the kernel. The machine I am using is dual bootable with
>> Windows NT and Linux. As a backup to the newly built kernel not working, I
>> am keeping a backup of the original kernel to boot with. As a test, I
>> copied the kernel to *.OLD, and added an entry in lilo.conf to point to the
>> newly created backup. I then ran lilo. The result of this was a warning
>> about the /dev/hdb7 not being on the first drive, followed by comments about
>> adding Linux *, LinuxOld and dos.
>> When I boot, I choose Linux from the Windows OS Loader, which invokes LILO.
>> However, now that I have changed lilo.conf, LILO prints out LIL- and locks
>> up.
>> Does anybody have an idea why this happens?
>> Is there some problem with LILO not being on the MBR?
>>
>> P.S. I subsequently went back to the old lilo.conf, ran lilo again, and I am
>> still getting the same results (LIL- and locks up).
>>
>> Thanks for the help,
>> Jay.
>>
>Did you rename the map file too? You have to keep the kernel file and map file
>synchronized so LILO can find both. Each version (I have three Linux versions
>installed) in /boot has both a kernel file and a matching map file. I match them by
>giving each map/kernel pair a common suffix - any one will do as long as it is
>different from other pairs. I have dual-booted W98 with Linux and never had to
>explicity copy the boot sector as Jean-Philip Robichaud suggests, but there may be
>some special issue(s) with NT.
LILO version 21.4.3 (06-May-2000) source at
ftp: sd.dynhost.com dir: /pub/linux/lilo
------------------------------
From: Brad Clawsie <[EMAIL PROTECTED]>
Subject: xntpd not starting at boot
Date: Sat, 24 Jun 2000 01:12:55 GMT
Hi.
I am having a problem with the standard RH6.2 xntpd package. It does not
start xntpd at boot time, even though /etc/rc.d/init.d contains the
xntpd script, which I am able to run manually like
# sudo /etc/rc.d/init.d/xntpd start
after the machine boots.
/var/log/boot.log and /var/log/messages do not show any boot time
activities regarding xntpd.
Anything obvious I am missing?
Thanks in advance for reading this and any solutions you may have.
Brad Clawsie
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: tye4 <[EMAIL PROTECTED]>
Subject: Re: function to get current year
Date: Fri, 23 Jun 2000 19:32:07 -0700
Currently, gcc/g++ (or any other compiler) are not compatible from one
version to another. Say, you write foo.c in Y2000 and recompile it Y2005. By
then, the compilers would have changed, and you would have to make minor
modifications in your code to get it to compile again, which is a big hassle
if you have a large application.
And again, similar to the infamous Y2K problem, programmers _have_ to
recompile all their applications, drivers, embedded systems etc. by Y2038.
Then reinstall all this software into the pertinent places -- major hassle.
I had hoped that the Y2K problem had brought awareness of spending too few
bits for the Year, and that either Posix standard, or glibc had a new
function that allows you to retrieve just the current year accurate to more
than two digits. A 32-bit year would mean no more worry about date problems
(whether the earth lasts for 4B years is really not that important).
If there is such a function in glibc, please let me know, otherwise I would
strongly suggest that such a function should be added to glibc:
eg:
file: time.h
unsigned int getcurrentyear();
Also, a new version of struct tm should be created to handle the 32-bit
year.
-tye4
PS: the current time_t does not support 4-digit years, its gives the number
of years since 1970. That is,
year = <year from time_t> + 1970
Which means time_t supports only 68 years, which is poor for something as
long-lasting as the Unix OS.
Erik Max Francis wrote:
> It is unclear to me what you're asking, and I suspect that you're asking
> for something you can't have, without knowing that what you're looking
> for is unnecessary in the first place.
>
> A 32-bit time_t can only hold dates to about 2038 (as you yourself
> pointed out earlier). If you're asking for a four-digit year meaning
> one that is valid past 1999, then you obviously already have one. If
> you're asking for a four-digit year meaning one that is valid up until
> 9999 AD, then a 32-bit time_t cannot possibly give you that.
>
> Use the Standard time routines as they exist. They will be valid until
> 2038, by which point all you'll need to do is recompile your
> Standard-compliant routines on an operating system that has an expanded
> time_t, and your time values will be valid up until the point at which
> that expanded time_t runs out.
>
> --
> Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
> __ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
> / \ When angry, count four; when very angry, swear.
> \__/ Mark Twain
> blackgirl international / http://www.blackgirl.org/
> The Internet resource for black women.
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Subject: Re: function to get current year
Reply-To: [EMAIL PROTECTED]
Date: Sat, 24 Jun 2000 03:25:47 GMT
Centuries ago, Nostradamus foresaw a time when tye4 would say:
>Currently, gcc/g++ (or any other compiler) are not compatible from one
>version to another. Say, you write foo.c in Y2000 and recompile it Y2005. By
>then, the compilers would have changed, and you would have to make minor
>modifications in your code to get it to compile again, which is a big hassle
>if you have a large application.
No, C has considerable compatibility between versions, as enough of
the behaviour of object code is specified by the ELF format as to be
useful in providing considerable inter-version interoperability.
On the other hand, no ABI has ever been defined for C++, and it
requires _CONSIDERABLY_ more interfacing than is "obvious" in ELF. So
for C++, you're quite right.
Mind you, if you build a source RPM, a BSD Ports package, or a Debian
source .deb, rebuilding may be _nearly_ as easy as "make world."
>And again, similar to the infamous Y2K problem, programmers _have_ to
>recompile all their applications, drivers, embedded systems etc. by Y2038.
>Then reinstall all this software into the pertinent places -- major hassle.
Did you know that on supercomputers like Crays, the policy often is
that applications are recompiled _EVERY TIME THEY RUN_?
Given the availability of competent tools like RPM, CVS, apt, rdist,
and such, I can't get too excited about a problem that is likely to be
solved naturally due to the fact that most computers only seem to have
a lifespan of _maybe_ ten years.
Which has the strange result that not only will the apps need to be
recompiled at least _once_ in the next 38 years, but the engineers are
likely to need to install new systems on the order of FOUR TIMES in
that period.
>I had hoped that the Y2K problem had brought awareness of spending too few
>bits for the Year, and that either Posix standard, or glibc had a new
>function that allows you to retrieve just the current year accurate to more
>than two digits. A 32-bit year would mean no more worry about date problems
>(whether the earth lasts for 4B years is really not that important).
No, I don't think you understand time_t. Contrary to your
impressions, it _doesn't_ express the date in years.
>If there is such a function in glibc, please let me know, otherwise I would
>strongly suggest that such a function should be added to glibc:
>eg:
>file: time.h
>unsigned int getcurrentyear();
>
>Also, a new version of struct tm should be created to handle the 32-bit
>year.
>
>-tye4
>
>PS: the current time_t does not support 4-digit years, its gives the number
>of years since 1970. That is,
>year = <year from time_t> + 1970
>Which means time_t supports only 68 years, which is poor for something as
>long-lasting as the Unix OS.
Have you ever looked at the tm struct? It happens to use an "int" to
represent the number of years since 1900. I am not aware of any
platform in active use on which this would _not_ support past year
67436.
I suggest that you simply wait for two years. Within _THAT_ period of
time, it is _highly_ probable that:
a) The increasing availability of 64 bit platforms, including PPC,
Alpha, SPARC, and possibly even IA-64 will encourage using 64 bit
values for time_t.
b) The increasing availability of 64 bit file sizes, supported by
ext2, ext3, ReiserFS, JFS, and XFS will encourage having stat()
support 64 bit sizes of both files _and dates_ on 32 bit platforms.
I suggest giving it two years to happen; that is probably a quite
sufficiently aggressive schedule to result in widespread
decommissioning of "32 bit time_t" systems well in time for 2038.
If it took _five_ years to happen, so that increased horsepower on the
likely-to-be-waning IA-32 platform would make the loss of performance
pretty irrelevant, that's probably _still_ enough lead time to let
_most_ of the systems that would be affected by the bug disappear, via
natural attrition, over the following 33 years.
A whole lot of "nuts" went "nuts" over this issue last year, as part
of the "Y2K paranoia" that saw some people stockpiling ridiculous
things in preparation for the predicted "end of the world." I
suggested then that solving the "2038 problem" could reasonably wait,
so long as it has _some_ attention, for a _couple_ of years.
Your misunderstandings provide me no reason to think that the "let the
64 bit attrition" deal with the problems will not suffice.
Heading back to your _FIRST_ point, the fact of "perhaps needing to
recompile" is the LAST thing that anyone working with Linux or FreeBSD
or OpenBSD or NetBSD ought to have the _slightest_ bit of concern
about. When the average distribution of _any_ of these systems has,
associated with it, many _GIGABYTES_ of source code, along with
automated tools to recompile that code, I just can't get excited about
this "problem."
The fact that C++ apps are difficult to keep interoperable at the
binary level just means that it's more important to compile them
locally, thus increasing the likelihood that they _need_ to be
deployed in "open source" form, which provides the "hooks" needed to
keep the code base open for future modification.
--
[EMAIL PROTECTED] - <http://www.ntlug.org/~cbbrowne/linuxy2k.html>
"Luckily for Microsoft, it's difficult to see a naked emperor in the
dark." --- Ted Lewis, (former) editor-in-chief, IEEE Computer
------------------------------
From: [EMAIL PROTECTED] (Paul Secinaro)
Subject: per process memory limit? (x86)
Date: 23 Jun 2000 23:49:37 -0400
Hi all,
I apologize if this is a faq, but I can't seem to find the answer online.
Anyway, what is the maximum amount of memory the current x86 Linux kernel
can address per process? I am running large digital circuit simulations
and have recently blown out the 2GB per-process limit of WinNT. Since our
simulation tools are also available on Linux, we were hoping we could get
a little more headroom for our x86 boxes before having to jump to a 64-bit
processor system. I believe I've heard the figure 3.75GB tossed around,
but I can't find anything definite.
Thanks,
Paul
------------------------------
From: Chris Rankin <au.zipworld.com@{no.spam}rankinc>
Subject: Lockup (Linux 2.2.16 + errata) while running "Terminus" demo ...
Date: Sat, 24 Jun 2000 13:54:30 +1000
Hi,
I thought I'd test my Linux installation on the Terminus game demo from
Vicarious Visions, and unfortunately the symptoms both times were:
- keyboard stopped responding
- the hard-disc light went on and stayed on
- the mouse pointer froze
- the screen graphics stopped updating
Needless to say that I had to reboot; the Alt-SysReq sequence didn't
seem to help me either. A subsequent post-mortem revealed the following
information:
/var/log/kernel:
Jun 24 12:34:15 wellhouse kernel: js: Joystick driver v1.2.15 (c) 1999
Vojtech Pavlik <[EMAIL PROTECTED]>
Jun 24 12:34:15 wellhouse kernel: joy-analog: no joysticks found
Jun 24 12:34:15 wellhouse kernel: VFS: Disk change detected on device
ide1(22,0)
Jun 24 12:34:15 wellhouse kernel: cdrom: This disc doesn't have any
tracks I recognize!
Jun 24 12:34:15 wellhouse kernel: VFS: Disk change detected on device
ide1(22,0)
Jun 24 12:34:15 wellhouse kernel: cdrom: This disc doesn't have any
tracks I recognize!
Jun 24 12:34:16 wellhouse kernel: Soundblaster audio driver Copyright
(C) by Hannu Savolainen 1993-1996
Jun 24 12:34:16 wellhouse kernel: SB 4.13 detected OK (220)
Jun 24 12:34:16 wellhouse kernel: Sound: Recording overrun
Jun 24 12:34:47 wellhouse last message repeated 1314 times
And my second attempt:
Jun 24 12:57:34 wellhouse kernel: js: Joystick driver v1.2.15 (c) 1999
Vojtech Pavlik <[EMAIL PROTECTED]>
Jun 24 12:57:34 wellhouse kernel: joy-analog: no joysticks found
Jun 24 12:57:35 wellhouse kernel: hdc: ATAPI 16X CD-ROM drive, 256kB
Cache
Jun 24 12:57:35 wellhouse kernel: Uniform CD-ROM driver Revision: 3.10
Jun 24 12:57:35 wellhouse kernel: VFS: Disk change detected on device
ide1(22,0)
Jun 24 12:57:35 wellhouse kernel: cdrom: This disc doesn't have any
tracks I recognize!
Jun 24 12:57:35 wellhouse kernel: VFS: Disk change detected on device
ide1(22,0)
Jun 24 12:57:35 wellhouse kernel: cdrom: This disc doesn't have any
tracks I recognize!
Jun 24 12:57:35 wellhouse kernel: Soundblaster audio driver Copyright
(C) by Hannu Savolainen 1993-1996
Jun 24 12:57:35 wellhouse kernel: SB 4.13 detected OK (220)
Jun 24 12:57:35 wellhouse kernel: Sound: Recording overrun
Jun 24 12:58:05 wellhouse last message repeated 1320 times
Jun 24 12:59:07 wellhouse last message repeated 2623 times
Jun 24 13:00:08 wellhouse last message repeated 2622 times
Jun 24 13:01:09 wellhouse last message repeated 2623 times
Now I might be wrong, but the messages *do* seem to point to the sound
support as being the trouble :-)! I have a Vibra 16-bit, configured as
follows:
alias char-major-14 sb
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
alias synth0 opl3
options opl3 io=0x388
These options play the sound for "Heroes of Might and Magic III" (and
everything else!) just fine and so I don't think that I have a
configuration problem. It looks as if the sound modules are just getting
stuck in this tight error loop, or something.
I am using OpenGL with XFree86 4.0 and ran the demo as a non-privileged
user; I am thinking "kernel-problem" because I wouldn't have expected a
non-privileged user to have been able to lock the machine up so
completely.
Can anyone comment, please?
Cheers,
Chris
------------------------------
From: Craig Curtis <[EMAIL PROTECTED]>
Subject: Error code 105
Date: Sat, 24 Jun 2000 04:02:23 GMT
I am attempting to run linux on a handheld 486. The unit may boot from an
internal flash array or PCMCIA ATA or SRAM card. Anyway, if I build the kernel
and dd it to an ATA flash disk, the unit attempts to boot off the disk.
However, it only prints 105's on the screen about one once a second. No other
text was written to the screen prior to the 105's, so this tells me that
something is happening before the start_kernel function, since the first thing
it does is put a banner on the screen. Does anyone have any ideas what could
cause this?
I am using 2.4 test1 kernel.
Thanks,
Craig Curtis
------------------------------
** 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
******************************
