Linux-Development-Sys Digest #957, Volume #6 Tue, 13 Jul 99 17:14:12 EDT
Contents:
Re: New OS development (Alex Wells)
vm86 ("overflow")
Re: Linux Internationalization? About code.. (Andi Kleen)
Re: NT to Linux port questions (Emile van bergen)
Re: Package manager as a VFS (Peter Samuelson)
simpleinit /etc/rc has no controlling terminal (Neil Faulks)
Re: gcc bug ([EMAIL PROTECTED])
Re: Package manager as a VFS (Mark WARDLE)
Re: 2.2.10/ppp/klogd problem (Paul Kimoto)
I need Help with modem drivers (Ranger)
Re: NT to Linux port questions (Matthew Carl Schumaker)
Re: simpleinit /etc/rc has no controlling terminal (Daniel R. Grayson)
Re: embedded linux in a specific application... ([EMAIL PROTECTED])
Re: when will Linux support > 2GB file size??? (Andreas Dilger)
Re: Kernel version 2.3.9+ (N1ho)
----------------------------------------------------------------------------
From: Alex Wells <[EMAIL PROTECTED]>
Subject: Re: New OS development
Date: Tue, 13 Jul 1999 16:37:06 +0100
Reply-To: [EMAIL PROTECTED]
Andrew Lipnitsky wrote:
> If you agree with me I will be glad to join this project.
>
> Best regards.
>
> Andrew.
Thankyou for your enthusiasm - I would greatly appreciate the extra help!
I've started to look at using OSKit as a foundation for the OS, as it has just
about everything that I need to get started. If there is anything else that you
can recommend as an alternative/bonus, I would be very grateful.
Regards,
Alex
--
Of all the things I've lost, I miss my mind the most
-- Ozzy Ozbourne
Veni, Vermini, Vomui - I came, I got Ratted, I Threw up.
------------------------------
From: "overflow" <[EMAIL PROTECTED]>
Subject: vm86
Date: Tue, 13 Jul 1999 17:31:30 +0200
I need some kind of documentation about the vm86() syscall. Is is it
supported by glibc? If it's not, how can I call it directly?
Jaime Medrano
[EMAIL PROTECTED]
Eurielec Linux
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Subject: Re: Linux Internationalization? About code..
Date: 13 Jul 1999 18:12:54 +0200
Hunkyu Chung <[EMAIL PROTECTED]> writes:
> Hi~ there,
>
> I live in South Korea. It's one of the countries which use multi-bytes
> character code.
> Well, I want to know the code internationization is considered under the
> kernel level.
Kernel internally uses UTF-8 (Unicode in 8bit encoding), which has the big
advantage that it requires no changes except at the "borders".
Borders:
- console driver supports unicode -> vga charset mapping in the vga limits,
if you need characters than can be put into a normal graphic card it needs
a special console emulator.
- FAT* file systems supports various ISO-XXXX -> UTF8 converter tables
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Tue, 13 Jul 1999 20:01:45 +0200
On Tue, 13 Jul 1999, Matthew Carl Schumaker wrote:
>But then aren't you going to end up polling that call, maybe not
>continously but at some interval.
Why? Just set the timeout to infinite, you can wait till _anything_
happens. In that case, view select like getmessage()/dispatchmessage(),
only you get to write dispatchmessage yourself, i.e. the concept doesn't
dictate that each and everything be event-driven...!
>While under windows you can write a network app that sets up a TCP Socket
>then sets up an event and tells Windows to send that event when there is
>data waiting on the port. THen you write an Event Handle (~Signal Handler
>under linux) that is called when you get data to read.
Okay, so this routine gets called. Asynchronously. The rest of the
program could do anything in the meantime. Where to record state between
calls to your handler? In global variables? Sheesh. No wonder windows
apps are buggy.
I'm very glad Unix lets me define my own flow of execution. If I want to
have multiple threads, I can have them without needing these cooperative
asynchronous hacks and I don't get event-drivenness forced down my
throat ;-).
>There is no select() or poll() statments needed to check for data, the
>OS does that for you and merely *tells* you that you have data to read
>so you can have your app doing other stuff in the mean time, like play
>chess or find the meaning to life :)
Sure. I would do non-related things in another, non-related process. Not
the same one...! Windows programmers really should get this type of
cooperative win-3.1 style multitasking out of their heads, I guess...
And if you absolutely want to, say you have an open handle to a socket
on which input in the chess window arrives, and an open handle to a
socket on which data may arrive you want to handle in another fashion,
you could easily do:
while(1)
{
FD_SET(chesswinfd,&myfdset);
FD_SET(tcpsocketfd,&myfdset);
cnt=select(max(chesswinfd,tcpsocketfd)+1,&myfdset,0,0,0);
/* wait for anything to happen that may possibly
interest you, block in the meantime; timeout=infinite */
if (cnt==-1) { perror("select"); exit(1);
if (FD_ISSET(chesswinfd,&myfdset) handlechessthingy();
if (FD_ISSET(tcpsocket,&myfdset) handletcpthingy();
}
How is this different than Windows, except that you can define your own
message dispatch loop instead of the OS forcing its own upon you? You
can get Unix as event-driven as you like it to be.
>I'm not saying you can't emulate this type of behavior,
>cause you certainly can, its just that it ain't pretty and isn't really
>worth the effort.
How are the above ~10 lines ugly?? If you'd go down the signals route,
it would become a mess... That's why you shouldn't.
>In my opinion Windows basically put another layer between the User and the
>OS that generally under Unix the user has to deal with.
Correct. But this is a tiny layer, its a simple move of one small loop
in this case.
Oh, and btw, where's the poll above? I don't see one... If you want to
do other things timed, you can add the timeout, ok, but you could also
see that as a periodic 'time event' coming in ;-).
I really don't see any disadvantage to this mechanism, sorry.
--
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.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: Package manager as a VFS
Date: 13 Jul 1999 07:58:09 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Mark WARDLE <[EMAIL PROTECTED]>]
> Although I quite like RPM etc..,
Well, I'm a dpkg man myself....
> it seems rather un-unix like to not implement something like this as
> a device/virtual filesystem when it would be ideally suited to
> managed packages on a system.
Actually it'd be rather un-unix-like to put such complex functionality
into such a low-level service as a filesystem. If you've ever studied
the actual details of how filesystems work you'll know what I mean.
Anyway, package management doesn't really fit the file paradigm at all.
Create and delete, yes. chown/chmod, maybe. But read? write?
truncate? mmap? mkdir? lseek? link? None of those fundamental file
operations have any obvious parallel with packages.
> Imagine uninstalling items just by rm'ing them from the package
> manager filesystem and installing just by copying. I don't think
> there's anything out there like that is there?
Closest thing I can think of is `stow'. It puts each pkg in its own
directory (so `rm -r' almost works...) and glues things together with
symlinks. The next closest thing would be Slackware .tgz packages
without the metafiles in them.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: Neil Faulks <[EMAIL PROTECTED]>
Subject: simpleinit /etc/rc has no controlling terminal
Date: Tue, 13 Jul 1999 16:16:57 GMT
I am building a linux installation from scratch. At the moment I am
evaluating simpleinit from util-linux-2.9u
When init executes the /etc/rc file it seems to deliberately close the
controlling tty. This means that e2fcsk will not run from /etc/rc,
which ought to be the correct place to put it.
Why does simpleinit do this?
Why does simpleinit run though all possible fds and try to close them
on startup (/bin/login does this too).
--
Neil Faulks
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: gcc bug
Date: Tue, 13 Jul 1999 16:16:51 GMT
In article <7mf5sb$8ns$[EMAIL PROTECTED]>,
"BennoG" <[EMAIL PROTECTED]> wrote:
> I think I have found a bug in GCC. When compiling the following code
without
> optimalisation on Intel platform the two lines should put out the same
> result.
>
No you haven't.
> int main()
> {
> double d1;
> d1=1.38;
>
> printf("var=%f ",d1*1800);
> printf("var=%d\n",(int)(d1*1800));
>
> printf("var=%f ",1.38*1800);
> printf("var=%d\n",(int)(1.38*1800));
> return 0;
> }
>
In this case, the function 'rint' would be the correct way
on converting:
printf("var=%d\n",(int)rint(d1*1800));
In other cases 'floor' would be better, but that depends on the
situation.
Welcome to the wonderful world of floating point calculations. ;-)
/Jonas U
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Mark WARDLE)
Subject: Re: Package manager as a VFS
Date: 13 Jul 1999 18:29:46 GMT
Reply-To: [EMAIL PROTECTED]
Peter Samuelson ([EMAIL PROTECTED]) wrote:
: Actually it'd be rather un-unix-like to put such complex functionality
: into such a low-level service as a filesystem. If you've ever studied
: the actual details of how filesystems work you'll know what I mean.
Ahh.. oops. I'm afraid I haven't - one of the reasons why I was trying to
think of something to mess around with so I might learn... *grin*
: Anyway, package management doesn't really fit the file paradigm at all.
: Create and delete, yes. chown/chmod, maybe. But read? write?
: truncate? mmap? mkdir? lseek? link? None of those fundamental file
: operations have any obvious parallel with packages.
Ahhh.. fair 'nough then. Basically, I was daydreaming about things like
activedirectory (*spit*) and fancied abstracting something like a package
manager onto a filesystem.
Anyway, better do some real work... ;)
Cheers,
Mark
------------------------------
From: [EMAIL PROTECTED] (Paul Kimoto)
Subject: Re: 2.2.10/ppp/klogd problem
Date: 13 Jul 1999 14:53:49 -0500
Reply-To: [EMAIL PROTECTED]
[newsgroups trimmed]
In article <7md31g$g66$[EMAIL PROTECTED]>, Peter Baker wrote:
> I recently compiled the 2.2.10 kernel on a pretty stock standard RH6.0
> system.
>
> Now when I dial up klogd goes into overdrive taking virtually all of
> one CPU (out of two) for itself. This doesnt happen under the standard
> 2.2.5 kernel that comes with RH6.0
I wonder which version of sysklogd RH is shipping
these days: the current version is 1.3-31 (at
ftp://ftp.infodrom.north.de/pub/people/joey/sysklogd).
--
Paul Kimoto <[EMAIL PROTECTED]>
------------------------------
From: Ranger <[EMAIL PROTECTED]>
Subject: I need Help with modem drivers
Date: Tue, 13 Jul 1999 15:51:31 -0400
I am a new Linux user (Mandrake) and unfortunately have a PC-tel HSP
MicroModem 56k and I can't find any drivers that will get my modem to
work ...so I a have to use Windoze 98 everytime I want on the internet
.....if someone cane help please respond .....I am getting tired of
useing windows and want to use Linux full time
------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Tue, 13 Jul 1999 15:29:46 -0400
Reply-To: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
On Tue, 13 Jul 1999, Emile van bergen wrote:
> On Tue, 13 Jul 1999, Matthew Carl Schumaker wrote:
>
> >But then aren't you going to end up polling that call, maybe not
> >continously but at some interval.
>
> Why? Just set the timeout to infinite, you can wait till _anything_
> happens. In that case, view select like getmessage()/dispatchmessage(),
> only you get to write dispatchmessage yourself, i.e. the concept doesn't
> dictate that each and everything be event-driven...!
By doing this you've removed the ability to have your app run
asynchronously, unless you wrap your calls into a thread
>
> >There is no select() or poll() statments needed to check for data, the
> >OS does that for you and merely *tells* you that you have data to read
> >so you can have your app doing other stuff in the mean time, like play
> >chess or find the meaning to life :)
>
> Sure. I would do non-related things in another, non-related process. Not
> the same one...! Windows programmers really should get this type of
> cooperative win-3.1 style multitasking out of their heads, I guess...
I'm playing the devil's Advocate here but Why? To the best of my
knowledge there hasn't been a study done that compares the virtues of a
"MS Windows Like" OS versus a "Unix Like" OS that says which is better
*notice that I'm not saying that MS did a good job of implementation of an
Event Driven model I'm saying Event vs Unix architectuure
> And if you absolutely want to, say you have an open handle to a socket
> on which input in the chess window arrives, and an open handle to a
> socket on which data may arrive you want to handle in another fashion,
> you could easily do:
>
> while(1)
> {
> FD_SET(chesswinfd,&myfdset);
> FD_SET(tcpsocketfd,&myfdset);
> cnt=select(max(chesswinfd,tcpsocketfd)+1,&myfdset,0,0,0);
> /* wait for anything to happen that may possibly
> interest you, block in the meantime; timeout=infinite */
>
> if (cnt==-1) { perror("select"); exit(1);
>
> if (FD_ISSET(chesswinfd,&myfdset) handlechessthingy();
> if (FD_ISSET(tcpsocket,&myfdset) handletcpthingy();
> }
>
> How is this different than Windows, except that you can define your own
> message dispatch loop instead of the OS forcing its own upon you? You
> can get Unix as event-driven as you like it to be.
>
> >I'm not saying you can't emulate this type of behavior,
> >cause you certainly can, its just that it ain't pretty and isn't really
> >worth the effort.
>
> How are the above ~10 lines ugly?? If you'd go down the signals route,
> it would become a mess... That's why you shouldn't.
>
See above argument for Asynchronous
>
> Oh, and btw, where's the poll above? I don't see one... If you want to
> do other things timed, you can add the timeout, ok, but you could also
> see that as a periodic 'time event' coming in ;-).
the polling is done by the while(1) {.......} loop
if your timeout is infine then you won't see much of a performance hit,
but as timeout -> 0 your performance will go down because CPU usage will
rise. But with an infinite timeout you loose some error checking
abilities due to the fact that you have an infinite timeout, for example
if a client doesn't return a value with in a specific time you resend the
data, etc. You've now lost this ability
>
> I really don't see any disadvantage to this mechanism, sorry.
I never said there were any disadvantages, I was merely pointing out some
of the pitfalls that one has to deal with when porting from NT to Unix
------------------------------
From: [EMAIL PROTECTED] (Daniel R. Grayson)
Subject: Re: simpleinit /etc/rc has no controlling terminal
Date: 13 Jul 1999 15:28:55 -0500
Neil Faulks <[EMAIL PROTECTED]> writes:
> I am building a linux installation from scratch. At the moment I am
> evaluating simpleinit from util-linux-2.9u
>
> When init executes the /etc/rc file it seems to deliberately close the
> controlling tty. This means that e2fcsk will not run from /etc/rc,
> which ought to be the correct place to put it.
Maybe you need to give the -p or -a option to fsck so it won't ask try to any
questions.
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: Re: embedded linux in a specific application...
Date: Tue, 13 Jul 1999 19:54:48 GMT
In article <[EMAIL PROTECTED]>,
William Ryder <[EMAIL PROTECTED]> wrote:
>...
> -is Linux available for such an application,
that is, are there real Linux kernels and sources
available right now?
Yes. There are many distros that can help you
directly and indirectly. Take a look at Linux
Weekly News (www.lwn.net) in the distribution
section. There are several micro (single
2-4MB floppy) distros that can get you started.
Most of these are made for the Intel processor
family, but one should get you started.
> -are there development tools available?
Yes... in a sense. I do not know of a
set of commercial tools, but there are plenty of
HOWTOs for creating a bootable floppy which can
then be converted into a bootable ROM.
> -are there companies that might be able to aid
us in development of kernel specific and/or
application code?
Yes. RedHat/Caldera/SuSE offer contract agreements
for assisting professional development. There are
several programmers that would love to help out.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
------------------------------
From: [EMAIL PROTECTED] (Andreas Dilger)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 13 Jul 1999 20:01:13 GMT
In article <[EMAIL PROTECTED]>,
Robert Krawitz <[EMAIL PROTECTED]> wrote:
>The IA-64 won't solve this problem, because there won't be enough
>software for business users. When I say "business users" I'm not
>referring to people who want an office suite for the desktop, but
>rather the data warehouse crowd. The reason that they're even
>considering Linux is that apps such as Oracle, DB/2, Tuxedo, and such
>are at last becoming available.
However, you are being misleading by mentioning "Enterprise" DB products,
since all of these products were handling many GB databases while the OS
only supported 2GB files. They also did the partitioning in the FS to
2 GB filesize limits, and connected the tablespaces internally.
IMHO, raw partitions are better for DBs anyways, since there are not problems
of FS corruption, no fsck time on boot, no 2GB size limit, less overhead, etc.
OS access permissions are not a valid arguement against this, as you can have
unix permissions on devices just as easily as files. If you use LVM instead
of the "DOS" partitions, you can even grow your partitions easily. All DB
vendors you mention support raw partitions today.
Cheers, Andreas
--
Andreas Dilger University of Calgary \"If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
------------------------------
From: [EMAIL PROTECTED] (N1ho)
Subject: Re: Kernel version 2.3.9+
Date: 13 Jul 1999 18:28:19 GMT
It would be nice if such a warning was put at the top of the README file so
that those of us who have been routinely regression testing development kernels
since the early 1.1 series would be alerted to *known* compilation
failure-inducing bugs. In professional OS's they're sometimes known as "Release
Notes". If there isn't a workaround, then why release the bloody tree in the
first place? As for reading the Kernel Notes, well, it's tough to do if you
can't get through to a site that's down all weekend and (as of last night)
hadn't been updated in over a week.
Save your sanctimonious comments about not touching development kernels for
those to whom it might apply. I'm proud to state that I downloaded and built
about 95% of the 2.1 kernels that were made available, and in several instances
pointed out regressions that others hadn't noticed (such as the SCSI driver
code that was re-written, but somehow broke the AHA-1740 driver). I can also
state that I built SMP kernels in the late 2.1.12* series and the 2.1.13*
series on a uniprocessor, and when I finally had the cash to buy a matching
pair of CPU's and install them, the kernels that I had built booted and worked
perfectly, which seems to underscore the veracity of my regression testing.
So, if I wonder why the same bloody problem carries over from one experimental
kernel to the other, it's in an effort to politely point out to the relevant
developers that perhaps there is still an underlying problem due to an arcane
corner case that they missed, or possibly a header file problem or some other
minor issue and that the bug ain't completely squashed yet. I seriously doubt
any one person or organization has all combinations of hardware to completely
regression test every kernel or every chunk of code to be contributed to the
tree. That's why the experimental kernels are out there and that's why I have
been testing them the last 5 years. I don't subscribe to the kernel mailing
list because I don't have time to wade through it all. It's a lot quicker and
easier to unpack a new kernel tree and check a text file or two for a list of
known problems and workarounds rather than wait several hours or a day or two
for someone to put up a page on the Web somewhere
telling me that the kernel tree is bad.
=====BEGIN GEEK CODE BLOCK=====
GCS/CC d+ s:+>: a+ C+++ UO++$L++>$ P L+++ E- W+ N++ K? w--- !O M? V--
PS+ PE+ Y+ PGP- t++ 5 X+ R* tv b++ DI+++ D? G e++ h+ r-- y--
=====END GEEK CODE BLOCK=====
Spam shared with [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 (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
******************************
