Linux-Development-Sys Digest #944, Volume #6 Fri, 9 Jul 99 12:14:19 EDT
Contents:
Re: ASSEMBLER problem (Josef =?iso-8859-1?Q?M=F6llers?=)
Re: Writing sound driver for Linux (Roope Anttinen)
Re: egcs weaknesses (was idiocy but let's be civil) (Peter Samuelson)
CDR creation date ? (THIERRY BUCCO)
Bi-directional parallel port device ("Dennis Schafroth")
Re: 2.2.10-ac8 won't link on sparc (Sverker Wiberg)
open a file inside kernel (Kuang-chun Cheng)
Re: CD-ROM File Time Bug (Peter Samuelson)
Re: embedded Linux and I2O... (mei)
Re: CD-ROM File Time Bug ("Thomas Steffen")
Re: ASSEMBLER problem (Martin Kahlert)
Re: Why we are still holding on to X Windows (Josef =?iso-8859-1?Q?M=F6llers?=)
NT to Linux port questions (Dave Rathnow)
Device Driver quesrions. (kilimanjaro robbs)
----------------------------------------------------------------------------
From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.kernel
Subject: Re: ASSEMBLER problem
Date: Fri, 09 Jul 1999 10:10:13 +0200
Josef M=F6llers wrote:
> =
> Vincent wrote:
> >
> > How can I put a varaible in a register
> >
> > void toto()
> > {
> > int val=3D0;
> >
> > __asm__("mov val,ax");
> > printf("%d\n", val);
> > }
> >
> > When I compil, I've this message: unindentifer ax !!!
> >
> > I've tryed with %ax but the variable val is always 0 but it's compil =
and
> > run.
> Have you tried different initialization values for val?
> =
> First of all, Linux is a 32-bit OS, so an int is 32 bits and you should=
> write "mov val,%eax". Secondly, the syntax of the __asm__ thingy is not=
> that simple, due to the structure of the compiler. In writing "mov
> <var>,%eax", you imply that <var> is a global variable, which it is not=
,
> in this context.
> =
> You might want to have a look at the gcc info (type "info gcc" and the
> follow "C Extensions" -> "Extended Asm"). Beware that it's pretty tough=
> stuff, though.
Ooops, hate to follow-up on myself, but isn't the direction under gnu
assemblers reversed?
mov source,destination
So it should be
mov %eax,val
if any,
Josef
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
------------------------------
From: Roope Anttinen <[EMAIL PROTECTED]>
Subject: Re: Writing sound driver for Linux
Date: 9 Jul 1999 08:43:48 GMT
Reply-To: [EMAIL PROTECTED]
lefebvre herve <[EMAIL PROTECTED]> wrote:
> Hi,
> Where can I find some docs/samples about writing linux drivers for sound
> cards ?
http://www.alsa-project.org
Roope
--
MicroSoft? is that some kind of a toilet paper?
PS: Look for address here, not from headers. And remove NOSPAM's
___________________________________________________________________________
[EMAIL PROTECTED] / [EMAIL PROTECTED]
+358 9 812 7567 / +358 500 445 565 / +358 49 445 565
http://myy.helia.fi/~anttiner/index.html
===========================================================================
Helsinki Business Polytechnic - Institute of information technology
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: egcs weaknesses (was idiocy but let's be civil)
Date: 9 Jul 1999 03:53:28 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Ian Hutchinson <[EMAIL PROTECTED]>]
> I was depressed by this thread because people seem to be admitting
> out of the box that egcs produces bigger and slower code than gcc.
You mean "bigger and faster". If small code is important, obviously
you have to use "-Os".
> I am left with only one possible advantage of egcs versus gcc and
> that is the integration of g77. All of the other areas sound like
> losses.
>
> Can someone point out some of the benefits I should be getting?
As mentioned already, "C++ that works".
Many bugs fixed.
Integration of gpc. (Not sure if that counts as an advantage.)
Much improved support for some targets.
Ability to compile glibc 2.1.
Many new and improved optimizations in generated code.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: THIERRY BUCCO <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.misc
Subject: CDR creation date ?
Date: Fri, 09 Jul 1999 10:32:51 +0200
Hi,
Is there a way to know the creation date of the first session about a
CDR ?
Thanks a lot
Thierry - FRANCE
------------------------------
From: "Dennis Schafroth" <[EMAIL PROTECTED]>
Subject: Bi-directional parallel port device
Date: Fri, 9 Jul 1999 11:27:25 +0200
Hi,
I am looking into moving our developement platform from SUN Sparc machines
to PC with Linux. This demands that Linux has a bi-directional parallel
port device, that can work as a bit pump with a constant bit rate (up to
1Mbit/s). Is the /dev/par* capable of this?
regards
Dennis Schafroth
------------------------------
From: Sverker Wiberg <[EMAIL PROTECTED]>
Subject: Re: 2.2.10-ac8 won't link on sparc
Date: Fri, 09 Jul 1999 11:29:58 +0200
Pete Zaitcev wrote:
>
> >When I tried to compile linux 2.2.10-ac8 on a sun4m (quad ross cpus),
> >the final link stage failed with the error
>
> > fs/filesystems.a(proc.o): In function `mem_read':
> > proc.o(.text+0x23b0): undefined reference to `pte_read'
> > proc.o(.text+0x23b0): relocation truncated to fit: R_SPARC_WDISP30
> >pte_read
> >[...]
>
> >/Sverker
>
> Many people complain about that... I do not use 2.2.x myself anymore
> so all I can suggest is to rip off the definition from 2.2.5 which
> was known to work.
Sorry, no pte_read in `linux-2.2.5/include/asm-sparc/*.h'. (Yes,
everybody else -- including sparc64 -- did have them (just like
2.2.10)). So it looks as I won't get any working ac-patch this week.
/Sverker
------------------------------
From: Kuang-chun Cheng <[EMAIL PROTECTED]>
Subject: open a file inside kernel
Date: 9 Jul 1999 09:52:28 GMT
Hi,
How can I open a file inside kernel, or device driver?
Does standard open(), read(), write() and close() still work? Thanks.
Kuang-chun Cheng
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Peter Samuelson)
Subject: Re: CD-ROM File Time Bug
Date: 9 Jul 1999 04:51:51 -0500
Reply-To: Peter Samuelson <[EMAIL PROTECTED]>
[Terry Boldt <[EMAIL PROTECTED]>]
> > > How does the 'system' know that the time stored on the CD-ROM is UTC?
[Peter Samuelson <sampo.creighton.edu!psamuels>]
> > Because you used a Unix variant to record it.
[Terry Boldt <[EMAIL PROTECTED]>]
> Hmm - so I have to rely on the world using one system - Unix - This
> sounds too much like MS to me.
If you want unambiguous timestamps, yes. Other OS's (AFAIK -- and I
don't really know) don't give you enough information to have any idea
which timezone is meant. In other words, Unix gives you more
information than The Other Guys. The extra information is what seems
to have confused you. If you don't want it, read on; I'll tell you how
to turn it off.
> > In other words, the Unix scheme is *predictable*. Other schemes
> > rely on knowing where the CD came from.
> Not at all - I only rely on what the person recording the CD says,
> either personally or by comparing with the file giving the directory
> listing incldued on the CD.
So ... to you it is not the actual time which is important, but the
fact that it agrees with some sort of external labeling. Thus
(contrary to your assertion) you do *not* actually care when the CD was
burnt, only when someone *says* it was burnt. This is an entirely
separate issue. In this case, for people like yourself, I suppose it
would be reasonable for the CD labeler to say "If you type `TZ=UTC0 ls
-lR' you will see:" instead of "If you type `ls -lR' you will see:".
> > Outside Unix, YMMV. But why would you want to go outside Unix? (:
> World domination by any factor is unpalatable.
As may be. Note smiley.
> My application MUST HAVE IDENTICAL REPORTING on all systems.
[...]
> I now know that for Unix variants the application must 'uncorrect'
> the displayed times/dates to get back to the times recorded by the
> originator as other systems expect.
If you really don't see the benefit of reporting times consistently
between timezones (and remember that a multiuser system like Unix does
not necessarily just use *one* timezone at a time), you can go back to
the MS-DOS way. It's really easy:
- Set your OS's TZ to UTC.
- If and when you change timezones, reset your hardware clock instead
of your OS timezone.
> > > And if the CD-ROM was recorded in Paris, both differ from the time
> > > the person in Paris thinks it was recorded.
> > Not if the person in Paris used a Unix variant.
> Yes even if the person in Paris used a Unix variant. Refer to my
> example from TurboLinux above.
I can see that we're not ever going to agree.
You seem to think that if something happens in Paris (UTC+1, IIRC) at
10:00, you should be told it happened at 10:00 YOUR time. I would
rather be told that it happened at 3:00 my time, since I am seven hours
behind Paris. The `ls -l' printout may not agree (since `ls' doesn't
print the timezone), but the reality *does* agree.
I believe my way (the Unix way) is better by virtue of being much more
deterministic. You apparently do not. Airplane pilots evidently agree
with me, because they always communicate times in UTC so that there is
never confusion about whose timezone they are talking about.
> > It *does* make sense. And implementing arbitrary special cases is
> > definitely not the Unix way, even if it were a good idea here,
> > which I contend that it isn't.
> If Unix doesn't have 'special cases' then why are there at least
> three version of the grep utility.
Not what I said, obviously. (a) You forgot my word "arbitrary". (b) I
didn't say Unix doesn't have them, just that it's not "the Unix way",
meaning they are not encouraged.
I've wondered about the three greps too. I believe GNU grep can do
them all with command-line switches, which is how I would have expected
the original to do it too.
> You have the wrong end of the stick. I noted the time the backup was
> recorded, not the elapsed time till I expect to use it. If I attempt
> to use the backup floppy three days later, I sure as heck am not
> going to rely on a calculation of the elapsed time.
So you noted the time the backup was recorded. 3 PM in New York, which
obviously is noon in LA. If you really have to travel between NY and
LA and are prone to forgetting that times are different between the
two, believe me, your backup floppy timestamps are the least of your
problems. Much more likely, you will run into trouble calling your NY
office from LA at 4 PM and wondering why you get the answering machine
that shouldn't have kicked in until 5:30.
> In checking the file time displayed against the time recorded, the
> two do not match because of the TZ 'correction'. Again refer to the
> TurboLinux example above.
> The 'system' may not not be able to reliably tell, but the
> appropriate device driver sure a heck should be able to tell.
I just went through this. I gave two examples of where it's hard to
tell if something should be considered removable or not. When I say
"system" I am certainly including the device drivers.
> The device driver for the CD-ROM should have some way of signalling
> the system that the media is removable and not to apply erroneous
> 'corrections'. The user could possibly over-ride where desired.
Not possible. The Linux kernel (and I suppose we ARE talking about the
Linux kernel here in c.o.l.d.s, right?) does NOT make the correction at
all. The correction happens in the `ls' utility. It does so by
calling timezone-handling functions in libc. Now `ls' has *no* easy
way of knowing whether it is listing "removable" files or not, and libc
sure as heck doesn't either.
If you want to list files on removable media and get "reliable"
timestamp behavior, it is very easy:
TZ=UTC0 ls -l ...
In other words, you explicitly tell `ls' that you are in UTC. End of
story.
> But you ARE making assumptions by blindly applying the TZ
> 'correction' to ALL file systems - irregardless of their type.
Yes. But you *have* to make at least one assumption. Your choice:
- Assume the files are timestamped in UTC. Then correct for the
user's timezone, because if the user didn't want this he would
have set his timezone to UTC. This is the Unix way.
or:
- Assume the files are timestamped in the current time zone, or may
as well be. This is the MS-DOS way.
The Unix assumption, in my view, is superior because both parties in a
transaction can always adhere to it. For the MS-DOS way to actually
work, one party or the other may have to change his TZ for the duration
of the transaction.
Now, *you* are making one additional assumption. You are assuming
that, for removable media, the "listed time as presented to the user"
usually matters more than the true global timestamp of a file. Again,
I disagree.
> Again the device driver or file system s/w written for the device or
> file system could be written to signal such information to the OS as
> appropriate.
Like I said, if you don't like the timezone correction, turn it off --
tell `ls' to use UTC. Just type "TZ=UTC0 ls" instead of "ls".
> Being blindingly 'consistent' may be good for machines, but I have
> never met a 'consistent' human - remember who is master and what is
> slave here.
Again, we are never going to agree about this. To me, determinism is
one of the coolest features of computers. I love not having to play
guessing games about what my computer means, like we humans are always
having to do.
--
Peter Samuelson
<sampo.creighton.edu!psamuels>
------------------------------
From: mei <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking,comp.os.linux.misc
Subject: Re: embedded Linux and I2O...
Date: Fri, 09 Jul 1999 12:32:22 +0200
Reply-To:
[EMAIL PROTECTED]
William Ryder ha scritto:
>
> Does anyone know of work being done to port Linux as a RTOS in an
> embedded, I2O environment. That is, is there a Linux that will run on
> embedded processors, complete with I2O API wrappers? If so, may I
> request appropriate websites and or e-mail addresses for the developers?
I saw there's some kind of work on I2O in the kernel 1.3.X, but I don't know
more.
Ciao Mei
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Subject: Re: CD-ROM File Time Bug
Date: 09 Jul 1999 13:19:48 +0200
Terry Boldt <[EMAIL PROTECTED]> writes:
> Peter Samuelson wrote:
...
> > No. You're looking at the problem wrong. Try this perspective:
> >
> > TZ=EST5EDT for the East Coast, we're in DST so time is -0400.
> >
> > - Back up file at 3:00 PM which is 19:00 UTC.
...
> > TZ=PST8PDT now, so time is now -0700.
> >
> > - Look at file. `ls' notes your time zone and says you created the
> > file at 12:00 noon.
...
> > It's entirely consistent. What is the problem?
> You have the wrong end of the stick. I noted the time the backup was
> recorded, not the elapsed time till I expect to use it.
^^^^^^^^
so if you are interested in timestaps, why do you record local time?
record universal time (since that's what it is ment for), and you'r
fine. if you use UTC, you wont have any problems with
timezones. because they don't matter. period.
--
linux, linuctis - f, das beste Betriebssystem ;-)
------------------------------
From: [EMAIL PROTECTED] (Martin Kahlert)
Subject: Re: ASSEMBLER problem
Date: 9 Jul 1999 12:10:11 GMT
Reply-To: [EMAIL PROTECTED]
In article <[EMAIL PROTECTED]>,
Vincent <[EMAIL PROTECTED]> writes:
> How can I put a varaible in a register
>
> void toto()
> {
> int val=0;
>
> __asm__("mov val,ax");
> printf("%d\n", val);
> }
Use:
#include <stdio.h>
int main(int argc,const char *argv[])
{
int val=0;
asm ("movl %%eax,%0" : "=g" (val));
printf("val = %d\n",val);
return 0;
}
Bye,
Martin.
--
esa$ gcc -Wall -o ariane5 ariane5.c
ariane5.c: 666: warning: long float implicitly truncated to unsigned type
esa$ ariane5
------------------------------
From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Fri, 09 Jul 1999 14:33:06 +0200
Michael Gu wrote:
> =
> Subject: Why we are still holding on to X Windows
> Date: Wed, 23 Jun 1999 16:29:17 -0400
> From: Junyang Gu <[EMAIL PROTECTED]>
> Organization: Silicon Systems, Inc.
> Newsgroups: comp.os.linux.advocacy
> =
> If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> Unix world.
> =
> Let's face it. X Windows is a really premitive base for modern GUI,
> terrible font support breaks GUI all the time, no sound capability, ...=
=2E
> If Linux is going to desktops to compete with Microsoft, it got to come=
> up with something much better then X.
> =
> So, why don't we drop the X and innovate?
Why should we drop a mechanism that's proven to be better that M$'s?
The font support is improving, with the new TrueType capable
font-servers.
The X windows system is a vehicle to transport graphical information
POSSIBLY ACROSS A NETWORK, not sound, there are other means to do that.
But if you think you can do better, feel free to do so, X is not a
monopoly, but nobody has come up with something better yet. And I guess
that lots of clever brains have tried.
But again: stop complaining, start working!
Josef =
-- =
PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!
------------------------------
Date: Fri, 09 Jul 1999 08:45:35 -0600
From: Dave Rathnow <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: NT to Linux port questions
Hi,
I'm in the process of redesigning an app that currently runs on NT
but will be ported to Linux eventually. Both platforms will alway need
to be supported so there will obviously be some conditional compilation
but since this app was originally implemented for NT, I'm concerned that
there may some NTism that don't have an equivalent under Linux.
I have two questions:
This application is event driving and uses the NT WaitForMultipleObjects
system call to wait on an array of events handles. The array
contains handles to a number of different event objects including NT
Events
timers, and thread handles. Does Linux have something similar. ie. a
mechanism
that allows a thread to wait for any one of a number of event to signal?
The second questions is about exception handling. This application is
written
in C++ and makes use of M$VC C++'s facility to translate structure C
exceptions
to C++ exceptions. Does such an animal exist in Linux or is that
something
that would be specific to the compiler?
Thanks in advance
Dave.
--
W. Dave Rathnow
Interprovincial Satellite Services Ltd.
Calgary, AB
http://www.intersatcorp.com
http://www.interfax.ca
mailto:[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (kilimanjaro robbs)
Subject: Device Driver quesrions.
Date: 9 Jul 1999 15:56:37 GMT
Reply-To: [EMAIL PROTECTED]
--
I am trying to write a device driver for the SIGG cyber i/o pci
card model number IO1842, It is a serial/parallel in one card.
If someone has already written a driver please contact me
my e-mail is
[EMAIL PROTECTED]
thanks
kilimanjaro.
------------------------------
** 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
******************************
