Linux-Development-Sys Digest #959, Volume #6 Tue, 13 Jul 99 23:13:48 EDT
Contents:
Re: when will Linux support > 2GB file size??? ("Stefan Monnier "
<[EMAIL PROTECTED]>)
Re: NT to Linux port questions (Robert Krawitz)
Re: NT to Linux port questions (Emile van bergen)
Re: NT to Linux port questions (Robert Krawitz)
Re: when will Linux support > 2GB file size??? (Robert Krawitz)
Re: NT to Linux port questions (Tristan Wibberley)
Re: when will Linux support > 2GB file size???
Re: I need Help with modem drivers (M. Buchenrieder)
Re: How to compile C++ in Linux? (Tristan Wibberley)
----------------------------------------------------------------------------
From: "Stefan Monnier <[EMAIL PROTECTED]>"
<[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 13 Jul 1999 21:09:23 -0400
>>>>> "Christopher" == Christopher Browne <[EMAIL PROTECTED]> writes:
> No, there are *two* missing things:
> a) FS that naturally supports large files,
ext2 has been supporting files up to 1TB for quite a while now.
> b) Applications that support large files.
You can have that right now:
- apply the Large-File-Summit (LFS) patch to your kernel
- use a recent glibc
- recompile your apps with I_CANT_REMEMBER_THE_FLAG_NAME
and that should be it. Some bad apps might break, but it's rather unlikely
since they would probably break in similar ways on all other Unixes.
Stefan
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: 13 Jul 1999 21:44:13 -0400
Matthew Carl Schumaker <[EMAIL PROTECTED]> writes:
> 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
Fine. So you're implicitly doing much the same thing in Windows, no?
It's executing some of your code out of band. Or use SIGIO if that's
what you really need.
> > >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
Because there's no single answer!
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Wed, 14 Jul 1999 03:00:14 +0200
On Tue, 13 Jul 1999, Matthew Carl Schumaker wrote:
>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
Yes. But my point is, your application _will_ (need to) block at some
point, otherwise it would consume 100% cpu, which is
probably unnecessary. With select() you can wait till _anything_
interesting happens. As I said before, there are _no_ events in unix
(apart from signals, but they can be converged to file io using a simple
pipe write) that cannot be waited for using select(). If you want a
blocking point, why not use select()? If you don't you're right, you're
best off using a separate process (or thread, if you must).
>> >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
That would be really interesting indeed... (no side intents here)! I
don't have any pointers myself to research in that area, but I'm highly
interested, as on Unix too, many GUI toolkits tend to work that way
(callbacks, event driven, everything asynchronous, dictated by the GUI
toolkit, you can't easily create a classic 'menu' screen-like UI with
some asynchronous aspects (i.e. only the menu bar), etc.). There must be
a good reason, but I don't exactly know why.
But I don't want to repeat nice discussion I had about those things,
which you can view btw. at
http://www.deja.com/dnquery.xp?DBS=2&QRY=xforms+%26+emile+%26+Allen&svcclass=dnold
then select the second message and view the thread.
Anyway, I was merely pointing out that you can easily create this event
model using a simple dispatch loop in unix.
[SNIP]
>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.
This specific time is what should be put in select()'s timeout, or in an
alarm() timer that interrupts select, or calls a signal handler that
writes something to a pipe of which the reading end is included in the
fileset you're select()ing on.
>> 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
Yup. And I was merely pointing out that they may not be as big as you
viewed/presented them... ;-)
--
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: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: 13 Jul 1999 21:40:59 -0400
Matthew Carl Schumaker <[EMAIL PROTECTED]> writes:
> Matthew Carl Schumaker
> UPAC Lights Administrative Chairperson
> [EMAIL PROTECTED]
> veni, vedi, velcro
> I came, I saw, I stuck around
>
> > > > select() can take a timeout, and you can specify a timeout of 0 or
> > > > anything less than 1E8 seconds
> > > But doesn't exectution of your routine halt while you call select or
> > > poll? This is blocking in my book. The Timeout just specifies a
> > > maximum amount of time that it will block
> >
> > *OF COURSE* execution of your routine halts while you call select or
> > poll. It halts whenever you call *any* system call. If *that's* what
> > you call blocking, there is *no* such thing as a non-blocking system
> > call.
> >
> > If you call select() with a timeout of 0, that is non-blocking in *my*
> > book.
> But then aren't you going to end up polling that call, maybe not
> continously but at some interval.
>
> 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. 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 :) 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.
There is SIGIO; one could also use another thread or process that
signals the main process when something's ready. A bit ugly, to be
sure, but if you need it, you need it.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 13 Jul 1999 21:55:26 -0400
[EMAIL PROTECTED] (Byron A Jeff) writes:
> In article <[EMAIL PROTECTED]>,
> Robert Krawitz <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Byron A Jeff) writes:
> -
> -Well, the very existence of a filesystem is a convenience; after all,
> -applications *could* use raw disk space themselves and parcel it out.
>
> A point that I have in fact been pounding. Such parceling at the application
> level doesn't make sense for small files. But we're talking about monster
> files here. Doesn't raw disk space at least merit a look?
Not amazingly, for the reasons below. Not to mention interoperability
between applications that might decide to lay out raw disk space
differently.
> -Some do and some don't. I consider using a raw partition to be a
> -major disadvantage, though, since it prevents using ordinary Unix
> -mechanisms (ownerships, permissions, backup, etc.) for managing the
> -files. I don't think people who want large amounts of data should
> -have to reinvent the filesystem.
...
> -> ext2 is very good at what it does the most. Adding 2G+ support will make it
> -> less good at what it does the most. So why change it?
> -
> -Well, OK, why would it make it less good?
>
> Because switching all the file pointer computations to 64 bit will slow each
> and every reference to the file system down on a 32 bit machine.
Or you could do the Solaris/AIX thing of having alternate system calls
for handling big files; you can use either system call for handling
small files. There's a compile-time macro that can be set for
recompiling old code with the new routines.
--
Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Tue, 13 Jul 1999 01:03:42 +0100
Reply-To: [EMAIL PROTECTED]
Andi Kleen wrote:
>
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
> >
> > Cheap, V. Cheap.
> >
> > I'm not sure of the exact details, but (basically and in principal). A
> > new stack frame is created (push the saved IP, push the saved BP and
> > assign the saved SP into BP) and the handler is executed (restore the
> > task state other than SP, BP and IP, which are set for the handler),
> > then the handler exits (ret) and your program continues exactly as if it
> > had just called a function (ie, as if nothing had happened - other than
> > what data the handler altered).
>
> Actually, it always reenters the kernel into sigreturn(), which does some
> book keeping like signal unblocking and then jumps back (into kernel or
> into user space, depends if it interrupted a system call and if the signal
> has SA_RESTART set)
I should have been more clear. I was just describing the fundamental
idea as unrelated to UNIX (UNIX signals are a high overhead extension -
in the same way that Cuprate superconductors are High Tc).
Signals are (would be if UNIX had the fundamental sigs as well as its
extended ones - and a couple more simple scheduler features) a v. good
way of performing a multi-processing method of waiting on multiple
sources. A process that gets told one of it's sources is ready just
signals the main process (which has been set up to not receive any CPU
cycles until it gets signaled). This is then very tidy, and very fast -
with a protected fault tolerant mechanism easily implementable,
separating dependancies on various components. Who cares for large fdset
support? :)
This is why The HURD is gonna be so useful for HA applications (if not
HP ones).
--
Tristan Wibberley
------------------------------
From: [EMAIL PROTECTED] ()
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: Tue, 13 Jul 1999 18:32:05 -0700
On Wed, 14 Jul 1999 00:32:08 GMT, Christopher Browne <[EMAIL PROTECTED]> wrote:
>On 13 Jul 1999 00:28:24 -0400, Byron A Jeff <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>Robert Krawitz <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Bones) writes:
>>-
>>-> >On Sun, 11 Jul 1999 01:31:04 GMT, [EMAIL PROTECTED] (Christopher B.
>Browne) wrote:
>>->
>>-> >I suspect that the "64 bit support on 32 bit architectures" thing will not
>>-> >happen quickly or soon. IA-64 should come out fairly soon, which will add
>>-> >up to *several* 64 bit architectures that should be suitable for those that
>>-> >really need big files. And that availability should diminish the urgency of
>>-> >"fixing" the problem on IA-32.
>>->
>>-> Plus pushing the issue now is kind of trivial, as another poster
>>-> pointed out, because of the small percentage of users who actually
>>-> need to be able to manipulate files >2GB.
>>-
>>-This "average user" thing is a nonsense, because there's no such thing
>>-as an "average user". For that matter, the percentage of users who
>>-need, say, support for a Matrox Millennium is considerably less than
>>-50%.
>>
>>Substitute "a majority of" for "average" and you start to get the point.
>>The percentage of users that require 2G+ files is much much smaller than the
>>Millennium crowd.
>
>This isn't a democracy.
>
>Free software is, generally speaking, a "tyranny of the implementors."
>The things that people work on tend to get implemented.
>
>The things that people don't work on definitely don't get implemented.
>
>This is particularly relevant in that we probably *do* have the two
>following populations:
>
>a) 10,000 Matrox Millennium users that would like support for the
>latest and greatest version of the card, but that contribute nothing
>to the effort, and
>
>b) An organization like Sandia Labs (picking a name at random), that
>represents a mere 100 users that want Real Big Files, but that is
>willing to pay $50,000 for a kernel developer to do the improvement to
>ext2.
>
>The net result of this scenario:
>- Big files get implemented
>- The 10,000 users that contributed nothing to the process will whine
> resultlessly.
>
>(The fact is that if those 10,000 users tossed $10 apiece "in the
>pot," that would provide $100,000 to help hire developers, which would
>provide the "economic signalling" to nicely indicate what they want,
>but seeing as how they're too cheap to do that, they are likely to
>continue to whine gracelessly and be ignored.)
Considering the relative states of Matrox drivers and
journaled file systems, these are two quite ironic
examples.
[deletia]
There are likely more people WRITING CODE that want good
matrox video support than want, or rather badly need,
multi-gigabyte files.
--
It helps the car, in terms of end user complexity and engineering,
that a car is not expected to suddenly become wood chipper at some |||
arbitrary point as it's rolling down the road. / | \
Seeking sane PPP Docs? Try http://penguin.lvcm.com
------------------------------
From: [EMAIL PROTECTED] (M. Buchenrieder)
Subject: Re: I need Help with modem drivers
Date: Tue, 13 Jul 1999 21:48:25 GMT
Ranger <[EMAIL PROTECTED]> writes:
>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
Without Win9*, this is just some unuseable equipment collecting dust.
>...so I a have to use Windoze 98 everytime I want on the internet
With that specific kind of non-modems, yes. These aren't real modems -
the work is done by (Win-)software instead of hardware.
>.....if someone cane help please respond .....I am getting tired of
>useing windows and want to use Linux full time
Then junk it and buy a real modem instead.
Michael
--
Michael Buchenrieder * [EMAIL PROTECTED] * http://www.muc.de/~mibu
Lumber Cartel Unit #456 (TINLC) & Official Netscum
Note: If you want me to send you email, don't munge your address.
------------------------------
From: Tristan Wibberley <[EMAIL PROTECTED]>
Subject: Re: How to compile C++ in Linux?
Date: Tue, 13 Jul 1999 02:05:38 +0100
Reply-To: [EMAIL PROTECTED]
Ryan Michaels wrote:
>
> I'm fairly new to Linux development.. most of the time I just use Perl. Is
> making a C/C++ program in Linux similar to that of Windows (DOS) where you
> write the program in a file, then compile it, or does Linux interpret it
> like Perl?
>
> I don't mean to ask such simple questions, but I can't seem to find any
> documentation on the system about this (if so, could you please let me
> know?).
C++ isn't the sort of thing that can be interpreted quickly (without far
more work than you really want to do). So it's fully compiled.
--
Tristan Wibberley
------------------------------
** 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
******************************
