Linux-Development-Sys Digest #953, Volume #6 Tue, 13 Jul 99 01:14:14 EDT
Contents:
Re: NT to Linux port questions (Matthew Carl Schumaker)
Re: interrupt handler in C (Philipp Thomas)
Re: open a file inside kernel (Philipp Thomas)
Re: egcs weaknesses (was idiocy but let's be civil) (Philipp Thomas)
Re: Project problem - linux printer port (David B Anderson)
Linux Internationalization? About code.. (Hunkyu Chung)
Re: when will Linux support > 2GB file size??? (Robert Krawitz)
Re: when will Linux support > 2GB file size??? (Rowan Hughes)
Re: NT to Linux port questions (Robert Krawitz)
Re: Kernel version 2.3.9+ (Philipp Thomas)
Re: CD-ROM File Time Bug (Philipp Thomas)
Re: when will Linux support > 2GB file size??? (Byron A Jeff)
----------------------------------------------------------------------------
From: Matthew Carl Schumaker <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: Mon, 12 Jul 1999 18:32:20 -0400
Matthew Carl Schumaker
UPAC Lights Administrative Chairperson
[EMAIL PROTECTED]
veni, vedi, velcro
I came, I saw, I stuck around
On Mon, 12 Jul 1999, Emile van bergen wrote:
> On Mon, 12 Jul 1999, Matthew Carl Schumaker wrote:
>
> >Tryimg uluate the WaitForMultipleObjects under LInux is terrible at
> >best(speaking from experience) the fact is that Linux/Unix and Windows
> >take two d different approaches to system apps. MS prefers events and
> >asynchronous stuff,(read the MSDN files about using the POSIX calls for
> >sockets that block, they say to use the WSA stuff instead)
> >while Linux/Unix prefers blocking calls. THe closest
> >things to MS Events under Linux are pthread signals but you can't wait 2+
> >simultaneous signals as in the WaitForMultipleObjects(fWaitAll = true).
> >System signals are poor replacements for MS Events since there are only 2
> >user defined signals and the majority of the other signals are meant to
> >kill the app. As for handles, They are supposed to be completely unique
> >and thus require some sort of routine(I think MS uses a combination of
> >hardware address(like MAC from the NIC) and time and date and a heafty
> >dose of black magic, But I'm not too sure about this)
>
> This story sounds like complete bogus to me. Sorry to be harsh, but I
> seriously think that you should read up on how Unix does things instead
> of 'finding the Linux equivalent to'. And even if you were about to do
> that, you could have done a better job.
>
Precisely my point, When I was working on the project, the company didn't
want to change their source so I had to implement the windows calls under
Linux, not pretty at all
> In unix, the 'objects' are called files. A process can have a handle to
> an open 'file'. It can be a (tcp/udp/unix) socket, a fifo, a terminal, a
> file, a sound card, whatever. It is, indeed, kind of an object.
>
True but not all of these handle are univerisal, in MS there is a data
type HANDLE that is used for any kind of handle let it be a file, window,
socket, device, etc
> Unix also has the ability to wait for something to happen on an object
> (e.g. it becoming ready to be read, i.e. 'data available', or ready to
> be written to (output empty), or some out-of-band event), and that
> ability is called select(). Read its man page, please. You _don't_ have
> to use blocking reads and then multithreading to overcome it!!
>
THe MS WaitForMultipleEvents has the ability to be called so it doesn't
return unless ALL handles become signaled SIMULTANEOUSLY select can't do
this. Not to mention using either select() or poll() heavily in program
can have very adverse effects on the speed of the program, and btw
select() and poll() are both blocking calls.
> Signals, otoh, are completely asynchronous and could occur anywhere in
> your program. Sort of like 'system interrupts' as opposed to
> hardware interrupts. Each one can be handled by a routine (signal
> handler) that you can attach to it.
>
To the best of my knowledge signal handlers are expensive things
> So use select() if you want to wait until _anything_ happens
> that has something to do with I/O (including a timeout), and then
> continue the flow of execution in the same routine. It is indeed very
> similar to some 'wait_for_multiple_objects' routine, because that's
> exactly what it does...! That's why I said you could have done a better
> job finding your equivalent.
>
> And if you absolutely insist on turning your program into spaghetti
> using callbacks all over the place, why not create a tiny select loop
> with a routine dispatcher in it for each filedescriptor that may become
> ready? Then you have the same mess you're probably used to.
>
> Use signals for asynchronous handling of catastrophes, or things that
> are almost completely isolated from the rest of the program (think when
> you would use an interrupt handler in DOS). Otherwise, where to record
> state? In some static global variables? Your app would turn into a mess
> very quickly, I guess.
>
> You could also create a fifo, have all signal handlers do nothing except
> write the signal number into it, and include the reading end of the fifo
> in your select loop. Voila, a message dispatch system using _one_
> routine (select()) for really (and I mean really) _all_ events that can
> possibly occur on a Unix system (except events like lightnings, power
> outage and such, of course ;-).
>
> Event driven programming may be nice in some aspects of implementing a
> GUI, but the thought of designing a complete application that way makes
> me shiver. Oh wait, VB/VC++ actually _encourages_ to design your app
> around the gui parts. Guess I almost forgot about that. Never mind ;-)
>
>
> --
>
> 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] (Philipp Thomas)
Subject: Re: interrupt handler in C
Date: Mon, 12 Jul 1999 22:43:52 GMT
On Fri, 9 Jul 1999 02:20:11 -0000, "klauspg" <[EMAIL PROTECTED]>
wrote:
>does anybody know if GCC (i386) can emit a function that is actually naked
>(no stack frame, no return).
gcc 2.95 does support __attribue__((naked)) if I remember correctly.
But you'd be better off asking directly on [EMAIL PROTECTED]
Philipp
--
You have moved your mouse. Windows must be rebooted for the
changes to take effect.
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: open a file inside kernel
Date: Mon, 12 Jul 1999 22:43:53 GMT
On 9 Jul 1999 09:52:28 GMT, Kuang-chun Cheng
<[EMAIL PROTECTED]> wrote:
> How can I open a file inside kernel, or device driver?
>Does standard open(), read(), write() and close() still work? Thanks.
Very simple, you can't. If you absolutely need to do it, have a
userspace app do the file I/O and feed it to the driver.
Philipp
--
You have moved your mouse. Windows must be rebooted for the
changes to take effect.
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: egcs weaknesses (was idiocy but let's be civil)
Date: Mon, 12 Jul 1999 22:43:50 GMT
On 9 Jul 1999 03:53:28 -0500, [EMAIL PROTECTED] (Peter
Samuelson) wrote:
>Integration of gpc. (Not sure if that counts as an advantage.)
That's *not* the case! It is planned to eventually integrate all
frontends, but currently gcc 2.95 has C, C++, Objective C, F77, Java
and Chill. Gpc (i.e. Pascal) is not yet in and will take some time to
do so.
Philipp
--
Close the windows! The penguin is freezing.
------------------------------
From: [EMAIL PROTECTED] (David B Anderson)
Subject: Re: Project problem - linux printer port
Date: 13 Jul 1999 00:42:32 GMT
In article <[EMAIL PROTECTED]>,
smith <[EMAIL PROTECTED]> wrote:
>Project problem - linux printer port
>
>
>I am trying to wire a simple video switch to the parallel port of a PC and
>have Linux
>it.
>
>So far I have made a connector that fools linux into beleiving that it has a
>printer
>connected, and have sent data to it.
You might find the book
Linux Device Drivers
by Alessandro Rubini
Pub by O'Reilly
useful. It seems surprisingly easy to
work with the parallel port
(and to test the parallel port), not that I've done
anything like it...
[EMAIL PROTECTED]
------------------------------
From: Hunkyu Chung <[EMAIL PROTECTED]>
Subject: Linux Internationalization? About code..
Date: Tue, 13 Jul 1999 09:46:43 +0900
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.
Thanks,
Habin
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 12 Jul 1999 22:31:45 -0400
[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%.
Yes, it's true that relatively few home or hobbyist users really need
big files. For that matter, I don't think most business users really
*need* big files per se, as there are other ways of storing even large
data warehouses that don't specifically require such large files, but
it's certainly convenient.
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. I don't want to hear anyone talking
about MySQL; it simply doesn't have the horsepower or even the basic
features (ever hear of ROLLBACK WORK?) to run this kind of stuff.
Scientific users -- the folks most people think of when the word
"supercomputer" comes up -- may not care as much because they're all
running custom stuff anyhow, and they're used to porting stuff at the
drop of a hat. But that dog won't hunt in the business world. These
guys really do need to handle a lot of data (the more the better as
far as they're concerned), and they also need the applications that go
along with them.
Furthermore, the problem Linux has with large files isn't the OS, but
the filesystem. glibc 2.1 doesn't have any problem with large file
offsets, but ext2 does, and I suspect that the VFS layer does also.
> Unlike some other OSes I could name, Linux doesn't keep its swap-file
> stored in the same filesystem as system and user data/apps. This is
> the only file that could realistically approach 2GB, and that an
> average user could come across. But even that example may be pushing
> it.
Let's not put up straw men, shall we? Big iron types (at least the
ones who know what they're doing) aren't interested in pitiful little
NT toys. The right comparison here is against Solaris and AIX, both
of which have supported big files for several years now. They do use
swap space, but if they're going to go 2 GB deep into it, they're
going to have a problem, which is why they're going to have those big
machines loaded to the gills with RAM (which is something else Linux
needs to fix). Any home user going 2 GB into swap space is likewise
going to be hurting badly for performance.
2 GB just isn't all that much data these days. We haven't reached the
point yet where a single image is 2 GB, but we're within striking
distance. And let's not fall into the trap Windows did with its
16-bit garbage.
--
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: [EMAIL PROTECTED] (Rowan Hughes)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 13 Jul 1999 02:27:29 GMT
In article <7m8qtt$[EMAIL PROTECTED]>, Byron A Jeff wrote:
[snip]
>So BTW why exactly do you need 2GB+ files?
They're needed more and more. In 6-12 months 50GB IDE disks
with media speeds of 30MB/sec will be the norm. I'm using
this sort of H/W already at work (GIS type stuff) and Linux
would get a lot more use in this field if it could do >2GB files.
--
=======================================================
Dr Rowan Hughes [EMAIL PROTECTED]
Qld Dept Natural Resources Forestry Bldg, 4.06
CIS group, Indooroopilly. W:07-38969705 H:07-38768083
------------------------------
From: Robert Krawitz <[EMAIL PROTECTED]>
Subject: Re: NT to Linux port questions
Date: 12 Jul 1999 22:44:08 -0400
Matthew Carl Schumaker <[EMAIL PROTECTED]> writes:
> On Mon, 12 Jul 1999, Emile van bergen wrote:
> > This story sounds like complete bogus to me. Sorry to be harsh, but I
> > seriously think that you should read up on how Unix does things instead
> > of 'finding the Linux equivalent to'. And even if you were about to do
> > that, you could have done a better job.
> >
> Precisely my point, When I was working on the project, the company didn't
> want to change their source so I had to implement the windows calls under
> Linux, not pretty at all
So it started life tied to Windows, and you expect that it's suddenly
going to trivially run under Linux without modification? Use winelib
if you must, or just do the port properly in the first place.
> > In unix, the 'objects' are called files. A process can have a handle to
> > an open 'file'. It can be a (tcp/udp/unix) socket, a fifo, a terminal, a
> > file, a sound card, whatever. It is, indeed, kind of an object.
> >
> True but not all of these handle are univerisal, in MS there is a data
> type HANDLE that is used for any kind of handle let it be a file, window,
> socket, device, etc
I don't know what "universal" means here, but a file descriptor
referring to a disk file is no different from one referring to a
socket or a device. That seems pretty generic to me.
Windows may be a bit harder, but it's still not too bad; just use
multiple threads or processes, with one thread waiting for the
appropriate X event and writing a byte to a file descriptor that your
main thread can select on. For that matter, skip the thread nonsense
and use processes.
> > Unix also has the ability to wait for something to happen on an object
> > (e.g. it becoming ready to be read, i.e. 'data available', or ready to
> > be written to (output empty), or some out-of-band event), and that
> > ability is called select(). Read its man page, please. You _don't_ have
> > to use blocking reads and then multithreading to overcome it!!
> >
> THe MS WaitForMultipleEvents has the ability to be called so it doesn't
> return unless ALL handles become signaled SIMULTANEOUSLY select can't do
> this.
So you want something that won't return until ALL of the objects
become ready? I would think that you'd want something to return as
soon as ANYTHING became ready. It's not too hard to emulate this in
any event: keep calling select() on everything that isn't yet ready
until everything has finally reported in. Put it in a library
routine, and nobody will be any the wiser.
Not to mention using either select() or poll() heavily in program
> can have very adverse effects on the speed of the program, and btw
> select() and poll() are both blocking calls.
This is simply false. select() can take a timeout, and you can
specify a timeout of 0 or anything less than 1E8 seconds (I have no
idea where that silly number came from). As for efficiency, try
measuring it before claiming that it will hurt performance.
> > Signals, otoh, are completely asynchronous and could occur anywhere in
> > your program. Sort of like 'system interrupts' as opposed to
> > hardware interrupts. Each one can be handled by a routine (signal
> > handler) that you can attach to it.
>
> To the best of my knowledge signal handlers are expensive things
Relatively so, because signals aren't intended as a general purpose
out of band signaling mechanism. Use threads or processes with
appropriate semaphores (which can be implemented in shared memory).
--
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: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: Kernel version 2.3.9+
Date: Tue, 13 Jul 1999 03:15:16 GMT
On Sun, 11 Jul 1999 21:35:59 -0400, "Zachary Kuznia"
<[EMAIL PROTECTED]> wrote:
>In the 2.3.9 and 2.3.10 kernels I have found an error compiling the fat
>module used to mount fat16 and fat32 drives. It finds an unresolved
Jeez, has all the discussion about the changes in buffer cache that
happened in *2.3.7* run past you ? Fat and other filesystems will
continue to not work for some time because they haven't been adapted
yet to the new scheme. If you need fat, stick to 2.3.6 and wait for
the changes to take place.
<SOAPBOX>
I just can't understand why anybody would try to use a development
kernel without *first* trying to get info on what works and what not.
Or at least try searching on dejanews *before* asking on the lists or
newsgroups.
After all, it's not called development kernel for nothing. Why do some
people still think that everything in a development kernel should work
?
</SOAPBOX>
Philipp
--
Close the windows! The penguin is freezing.
------------------------------
From: [EMAIL PROTECTED] (Philipp Thomas)
Subject: Re: CD-ROM File Time Bug
Date: Tue, 13 Jul 1999 03:15:13 GMT
On Sun, 11 Jul 1999 19:19:49 -0500, "Terry D. Boldt" <[EMAIL PROTECTED]>
wrote:
>situation.??? Also none of the filetimes agree with the DOS or OS/2
>filetimes. So I have four sets of filetimes:
>
>1) Linux translated to local
>2) Linux left in UTC - I guess (TZ='')
>3) The manufacterers filetimes (timezone setting unknown)
>4) DOS and OS/2 filetimes
If you're using OS'es like Windows, it's best to leave the hardware
clock at local time. To correctly set the time zone, you not only have
to set TZ correctly but also have to set /etc/localtime to point to
the correct zone (i.e. symlink it correctly). If I remember correctly,
zic is the right tool for it (I could be grave wrong, but I just do
the link directly, which in my case is /etc/localtime ->
/usr/share/timezone/Europe/Berlin).
Philipp
--
You have moved your mouse. Windows must be rebooted for the
changes to take effect.
------------------------------
From: [EMAIL PROTECTED] (Byron A Jeff)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: when will Linux support > 2GB file size???
Date: 13 Jul 1999 00:09:51 -0400
In article <[EMAIL PROTECTED]>,
Rowan Hughes <[EMAIL PROTECTED]> wrote:
-In article <7m8qtt$[EMAIL PROTECTED]>, Byron A Jeff wrote:
- [snip]
->So BTW why exactly do you need 2GB+ files?
-
-They're needed more and more. In 6-12 months 50GB IDE disks
-with media speeds of 30MB/sec will be the norm. I'm using
-this sort of H/W already at work (GIS type stuff) and Linux
-would get a lot more use in this field if it could do >2GB files.
I see your point, to a point. I still see this as a somewhat minor
inconvenience to one segment of the developer population at the risk of
destabilizing everything for everyone. The limit is only at the file level and
for good reason which is that 32 bit machines naturally only represent ints
up to 2G (with another 2G for negative indices). If we move everyone to an
unnatural size size to simplify things for a few applications, we risk the
danger of reducing the stability and performance of a filesystem that handles
a great majority of the file/application population in its current state.
Again I reiterate that the filesystem can handle disks that you propose above,
but only in 2G file increments. A 50G disk can be completely mapped in 25 2G
files. Even a terabyte array only requires 500 or so files to cover it.
Has anyone thought of writing a large file interface or class for this type of
activity? It seems to me its a relatively minor adjustment to map a set of
files in size up to 2G over a larger array. Or maybe a filesystem specifically
designed for handling large files?
I'd just hate to see the elegance and power of the existing filesystem be
compromised by fulfilling the needs of a few when other relatively simple
avenues exists to solve the problem.
Of all the examples I've seen only databases seem to warrant such a significant
change. And databases could in fact have better performance be implementing
a rudimentary filesystem for the data on top a the raw partition.
I'm just looking for a compelling reason to switch everything. I haven't seen
it yet.
BTW I'd agree if ext2 or other Linux filesystems were limited to 2GB
filesystems. But 2G files and managing small to moderate collections of them
seems to be more than adequate for the vast majority of applications out there.
Consider this: If a switch to a 64 bit filesystem occurs then every
application that does a seek on that filesystem must be recompiled. Every
data block pointer in every inode will double in size. Every data block
computation will require 64 bit arithmatic.
Be careful what you wish for. You may just get it.
BAJ
------------------------------
** 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
******************************
