Linux-Development-Sys Digest #648, Volume #7 Fri, 3 Mar 00 05:13:15 EST
Contents:
Re: Absolute failure of Linux dead ahead? (David T. Blake)
Re: Absolute failure of Linux dead ahead? (Grant Edwards)
Re: Absolute failure of Linux dead ahead? (Takeyasu Wakabayashi)
unmmaped area? (Weiguang Shi)
sndconfig with NeoMagic 256AV soundcard... ("Jae H. Choi")
Documentation for developing usb device drivers ("Pang")
Re: Backing out of ext3 filesystem (Sander van Malssen)
Is there any flush mechanism for scsi drivers? ("Brian")
Re: Absolute failure of Linux dead ahead? (Anders Larsen)
Re: Absolute failure of Linux dead ahead? (Anders Larsen)
Re: Moving our product line to Linux (Mathias Waack)
mapping between VFS system calls and C library APIs (Mace =?iso-8859-1?Q?Ga=EBl?=)
Re: unmmaped area? (Mathias Waack)
problem with cdrecorder and linux 2.2.13... (Thierry BUCCO)
Re: unmmaped area? (Fabrice Peix)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (David T. Blake)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 3 Mar 2000 03:40:48 GMT
Reply-To: [EMAIL PROTECTED]
Michael Sawyer <[EMAIL PROTECTED]> wrote:
> There's a problem here which seems largely overlooked in this
> discussion.
>
> Joe Programmer writes a program, and does the "Right Thing," using
> sizeof(time_t) anywhere he has to know the actual size of the type.
> The program he's writing needs to keep some data on disk, which is not
> at all an uncommon request. He's choosen to keep them in binary
> files, to save storage space. Thus, he's got some structure
> struct WHATEVER {
> time_t modification_time;
> int some_data;
> int some_other_data;
> char some_more_data[80];
> } ;
>
> This structure now gets written to disk.
>
> Now, time_t gets promoted to 64 bits, and he goes to read his data
> back from his disk file. We have a problem here, and there's not an
> obvious solution. He's got three choices as I see it: Demote all of
> his time_t's in the structure saved to disk to 32 bits, and have some
> magic code to re-promite it to 64 bits when it gets read in and
> written out, which has the means the file format never changes, but
> the first field in the struct is no longer *really* time_t, but
> something else. He can also provide a little additional program to
> reformat the files once he compiles with a 64-bit time_t, which is
> probably an acceptable solution if he's the only one using the
> program, but if it is a widely distributed thing, it's not good to ask
> every user to have to do that also. Finally, he can make his program
> smart enough to tell when 32-bit time_t's are used instead of 64 bit
> ones, and rewrite the file for the user if it discovers it.
Naw, you missed the most obvious option. Write the record size
in bytes as the first argument to the binary file, in a
fixed byte size unsigned integer, probably 32 bit. Then, the
program that reads in the binary file can read the first argument
to see if he needs to read in time_t as 32 or 64 bit. If we are
reading it in on a 64 bit machine, the first argument always gets
cast to 64 bits, and vice versa.
size_t presents a bigger problem - or rather, programmers that
cast it to integers are the big problem. Under several Unix
flavors size_t is an unsigned long (64 bits) which doesn't
cast well to a 32 bit integer with all compilers. size_t is
also more common (IME) than time_t since malloc and sizeof calls
are quite common.
foo
--
Dave Blake
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 03 Mar 2000 05:46:23 GMT
In article <[EMAIL PROTECTED]>, David T. Blake wrote:
>There is one and only one reason that x86 still exists. Microsoft.
>
>If they were capable and willing to port Windows to another platform,
NT has been available on the Alpha for quite a while. AFAIK, it's a
dismal failure. Everybody I've talked to with an Alpha runs Unix.
--
Grant Edwards grante Yow! I just forgot my
at whole philosophy of life!!!
visi.com
------------------------------
From: Takeyasu Wakabayashi <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: 03 Mar 2000 15:11:07 +0900
[EMAIL PROTECTED] (Grant Edwards) writes:
> Everybody I've talked to with an Alpha runs Unix.
And not OpenVMS?
(I'm a Linux/Alpha user, though. :-)
--
Takeyasu Wakabayashi
Faculty of Economics, Toyama University
[EMAIL PROTECTED]
------------------------------
From: Weiguang Shi <[EMAIL PROTECTED]>
Subject: unmmaped area?
Date: Thu, 2 Mar 2000 23:41:50 -0700
Hi, there:
I am wondering if there are parts of the physical memory under Linux
which are not included in the paging system (i386). I mean if there is
physical memory which is not used for paging but rather reserved for
other use in Linux.
Can you give some clue or could you please give a pointer to further
information?
Thanks.
Weiguang
Weiguang Shi | E-mail: [EMAIL PROTECTED]
Department of Computing Science | http://www.cs.ualberta.ca/~wgshi
University of Alberta | Office: CAB 481
Edmonton, AB, Canada, T6G 2H1 | (O) (780)492-3927
------------------------------
From: "Jae H. Choi" <[EMAIL PROTECTED]>
Subject: sndconfig with NeoMagic 256AV soundcard...
Date: Fri, 3 Mar 2000 02:13:25 -0500
Hell, I am trying to config my soundcard which is NeoMagic 256AV.. when I
run sndconfig command, it detects the soundcard correctly... However, it
gives me warning that it is known to crash some models of dell inspiron
which is irrelevant issue with my notebook... (I am using Sharp Actius
A800) After the warning sign, if I choose to continue, the config just
stops and does not proceed from then on... Does anybody have same problem
with me?? I downloaded the lastest driver for NeoMagic 256Av however, it
still does not work.. If anybody knows the solution or have faced same
problem please let me know...
Thank you...
Jae H. Choi
[EMAIL PROTECTED]
------------------------------
From: "Pang" <[EMAIL PROTECTED]>
Subject: Documentation for developing usb device drivers
Date: Fri, 3 Mar 2000 15:24:39 +0800
Hi,
Can anyone tell me where I can obtain documentations for developing usb
device drivers for linux? Thanks.
Pang
------------------------------
From: Sander van Malssen <[EMAIL PROTECTED]>
Subject: Re: Backing out of ext3 filesystem
Date: Fri, 03 Mar 2000 09:43:43 +0100
C. Chan wrote:
>
> In article <[EMAIL PROTECTED]>,
> Sander van Malssen <Anonymous, Reply> wrote:
> >
> >No problem, the on-disk formats for ext2 and ext3 are exactly the same
> >(apart of the
> >journal file which is really just an ordinary file in the file system).
> >You can switch
> >back between the two as much as you want, as long as the filesystem is
> >unmounted properly
> >before remounting it with the other fs type.
>
> That's what I thought, but when I tried it I got:
>
> Feb 29 13:49:23 localhost kernel: EXT2-fs: ide0(3,3): couldn't mount
> because of unsupported optional features.
>
> I'm pretty certain the filesystem was cleanly unmounted under ext3.
You might want to try mounting and unmounting as ext3 again, just to
make sure.
If that doesn't help, well, maybe you just found a bug in ext3 and you
might want
to report it to the ext3 author. (It's still development code, after
all.)
Cheers,
Sander
------------------------------
From: "Brian" <[EMAIL PROTECTED]>
Subject: Is there any flush mechanism for scsi drivers?
Date: 3 Mar 2000 08:55:20 GMT
Hi,
As far as I know low-level scsi drivers have to take care of actions like
"detect", "release", "queuecommand", "command", "abort", "reset",
"bios_param", etc. But I don't see how a low-lever scsi driver handle the
"flush" action. If a scsi card has build-in cache, how does system ensure
that the cache is flushed when it is going to shutdown? The scsi card may
still have data in the cache even though it reports to the system that all
queued commands have completed.
Brian
------------------------------
From: Anders Larsen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 03 Mar 2000 09:44:40 +0100
[EMAIL PROTECTED] wrote:
>
> Anders Larsen <[EMAIL PROTECTED]> spewed this unto the Network:
> >[EMAIL PROTECTED] schrieb:
> >>
> >> In article <[EMAIL PROTECTED]>,
> >> [EMAIL PROTECTED] wrote:
> >>
> >> [snip]
> >>
> >> > Wait, wait! There are other scary items forthcoming:
> >> >
> >> > a) Resolution of the 2038 problem. 2^31-1 seconds from Jan 1, 1970
> >> > happens to be in 2038. Stuff Will Break Then.
> >> >
> >> > This is the end-of-epoch that is the UNIX equivalent to the "Year
> >> > 2000 cliff" that everyone worried last year about.
>
> [snip]
>
> >It might be true that in 2038 most people don't care about what happened
> >before 2000-01-01, but the *transition* would be tough anyway.
> >
> >One could, however, perhaps consider changing time_t from signed to
> >unsigned - that would add another 68 years to the life-time of the
> >32-bit time_t.
>
> However, it would no longer be possible for time_t-returning functions
> to return -1 in the event of an error.
True, but one could test agains ~0 instead.
I know, I know, returning -1 in case of failure is *standard*; but do we
really have to sacrifice 50% of the possible range of values because of
*one single* return value?
> Another way to expand the lifetime of the 32-bit time_t is to make it
> 64-bits long by declaring it as 'long long'.
This would break a heckuva lot of applications which stores time_t in
disk files (as others have already commented).
--
Anders Larsen
------------------------------
From: Anders Larsen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy
Subject: Re: Absolute failure of Linux dead ahead?
Date: Fri, 03 Mar 2000 09:58:00 +0100
Mr Foo Bar wrote:
>
> <snip>
>
> >
> > Well, I really don't care that much, however - I believe 64+ bit
> > machines will be the norm before 2038 (and I'll be eighty by then ;-)
>
> Yes and drawing a pension ? Into which you made contributions ? Starting
> before 2000 ? :-)
The managing of pension funds and the like is a task that traditionally
is carried out on some big iron by a program written by - quote Edward
Yordan - "...brain-dead COBOL programmers..." ;-)
The Y2038 problem is a non-issue there (but they are the ones who had the
bulk of the Y2K problems).
Anyway, we are not in a hurry solving the Y2038 problem - most Y2K
problems were actually solved in time, even though quite a number of
companies did not start working on it until less than one year before the
deadline!
Having 37 years to think up a bright solution really is comforting,
considering that the problem might simply vanish due to hardware changes.
--
Anders Larsen
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: Moving our product line to Linux
Date: Fri, 03 Mar 2000 10:07:19 +0100
Edward Balassanian wrote:
> As I understand it, X provides a shared memory facility that is effectively
> like writing direct to the frame buffer. This would be ideal for us. What
> we don't want is a ton of layering between us and a device since we are
> focused on high-bandwidth multimedia rendering.
XFree4.0 will provide such low level but high speed layer. You can find more
information at http://www.xfree86.org, especially
http://www.xfree86.org/3.9.18/DESIGN.html
may be interesting for you.
Mathias
------------------------------
From: Mace =?iso-8859-1?Q?Ga=EBl?= <[EMAIL PROTECTED]>
Crossposted-To: linux.dev.c-programming
Subject: mapping between VFS system calls and C library APIs
Date: Fri, 03 Mar 2000 09:11:00 +0000
==============DB914C4FEC695957AE2046DB
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Hi,
For my own understanding, does someone can explain me the mechanism /
implementation of the mapping between the VFS system calls and the
standard C library APIs (e.g. glibc) ?
If I'm not wrong, in the linux architecture, the VFS module presents
several APIs (in <fs.h> such as sys_open, sys_statfs, etc.) which are
unified system calls independent of the physical file system. At a upper
level, I can find in the implementation of the standard C library (such
as glibc) some related APIs (in <fcntl.h> such as open, stat, etc.).
However, by studying the source code of the glibc library, I fall in
some dead ends and never find direct (or indirect) relation between VFS
interface and standard interface.
By example for the glibc 2.1 implementation, in the file
"sysdeps/generic/open.c"
#include <errno.h>
#include <fcntl.h> <<== include these declarations
==> extern int __open __P ((__const char *__file, int __oflag,
...));
#include
<stdarg.h> extern
int open __P ((__const char *__file, int __oflag, ...));
#include <stddef.h>
/* Open FILE with access OFLAG. If OFLAG includes O_CREAT,
a third argument is the file protection. */
int
__open (file, oflag)
const char *file;
int oflag;
{
int mode;
if (file == NULL)
{
__set_errno (EINVAL);
return -1;
}
if (oflag & O_CREAT)
{
va_list arg;
va_start(arg, oflag);
mode = va_arg(arg, int);
va_end(arg);
}
__set_errno (ENOSYS);
return -1; <<== does this function return
always -1 ????
}
stub_warning (open) <<=== What's that ?
weak_alias (__open, open) <<=== what's that also ?
Thanks in advance for your help
--
Ga�l MACE
===>> Speed can kill, use Windows <<==========
==============DB914C4FEC695957AE2046DB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>For my own understanding, does someone can explain me the mechanism
/ implementation of the mapping between the VFS system calls and the standard
C library APIs (e.g. glibc) ?
<p>If I'm not wrong, in the linux architecture, the VFS module presents
several APIs (in <fs.h> such as sys_open, sys_statfs, etc.) which
are unified system calls independent of the physical file system. At a
upper level, I can find in the implementation of the standard C library
(such as glibc) some related APIs (in <fcntl.h> such as open, stat,
etc.).
<p>However, by studying the source code of the glibc library, I fall in
some dead ends and never find direct (or indirect) relation between VFS
interface and standard interface.
<p>By example for the glibc 2.1 implementation, in the file "sysdeps/generic/open.c"
<br>
<br><tt>#include <errno.h></tt>
<br><tt>#include
<fcntl.h>
<<== include these declarations ==>
extern int __open __P ((__const char *__file, int __oflag, ...));</tt>
<br><tt>#include
<stdarg.h>
extern int open __P ((__const char *__file, int __oflag, ...));</tt>
<br><tt>#include <stddef.h></tt><tt></tt>
<p><tt>/* Open FILE with access OFLAG. If OFLAG includes O_CREAT,</tt>
<br><tt> a third argument is the file protection. */</tt>
<br><tt>int</tt>
<br><tt>__open (file, oflag)</tt>
<br><tt> const char *file;</tt>
<br><tt> int oflag;</tt>
<br><tt>{</tt>
<br><tt> int mode;</tt><tt></tt>
<p><tt> if (file == NULL)</tt>
<br><tt> {</tt>
<br><tt> __set_errno (EINVAL);</tt>
<br><tt> return -1;</tt>
<br><tt> }</tt><tt></tt>
<p><tt> if (oflag & O_CREAT)</tt>
<br><tt> {</tt>
<br><tt> va_list arg;</tt>
<br><tt> va_start(arg, oflag);</tt>
<br><tt> mode = va_arg(arg, int);</tt>
<br><tt> va_end(arg);</tt>
<br><tt> }</tt><tt></tt>
<p><tt> __set_errno (ENOSYS);</tt>
<br><tt> return
-1;
<<== does this function return always -1 ????</tt>
<br><tt>}</tt>
<br><tt>stub_warning
(open)
<<=== What's that ?</tt><tt></tt>
<p><tt>weak_alias (__open,
open)
<<=== what's that also ?</tt>
<br>
<p>Thanks in advance for your help
<pre>--
Gaël MACE
===>> Speed can kill, use Windows <<==========</pre>
</html>
==============DB914C4FEC695957AE2046DB==
------------------------------
From: Mathias Waack <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Date: Fri, 03 Mar 2000 10:11:06 +0100
Weiguang Shi wrote:
> I am wondering if there are parts of the physical memory under Linux
> which are not included in the paging system (i386). I mean if there is
> physical memory which is not used for paging but rather reserved for
> other use in Linux.
The memory used by the kernel itself is not used for paging. But I'm not
sure, if this was the answer for your question...
Mathias
------------------------------
From: Thierry BUCCO <[EMAIL PROTECTED]>
Subject: problem with cdrecorder and linux 2.2.13...
Date: Fri, 03 Mar 2000 01:34:54 -0800
Hi,
Is there anybody has got this problem ?
1- I write a session in a cdrom with cdrecord (cdrom still open)
2- I mount the cd and i see the session OK
3- I umount the cd
4- I write another session into cdrom (cdrom still open)
5- I mount the cd and i don't see the new session, only the first...
i must open the tray an close the tray to see the new session.
I guess the TOC is not read refresh after first session, is there a way to
see the new session without open the tray ?
With a 2.0.36 kernel it work fine, but now with the new 2.2.13 kernel, i
have this problem.
my Linux Box contains :
Linux 2.2.13 RedHat 5.2
Adaptec SCSI Card 2904
Yamaha 8424 cdrecorder
Thanks a lot for your help.
Thierry - FRANCE
------------------------------
From: Fabrice Peix <[EMAIL PROTECTED]>
Subject: Re: unmmaped area?
Date: Fri, 03 Mar 2000 11:06:11 +0100
Mathias Waack wrote:
>
> Weiguang Shi wrote:
> > I am wondering if there are parts of the physical memory under Linux
> > which are not included in the paging system (i386). I mean if there is
> > physical memory which is not used for paging but rather reserved for
> > other use in Linux.
>
> The memory used by the kernel itself is not used for paging. But I'm not
> sure, if this was the answer for your question...
>
> Mathias
I thing you are wrong , paging system is made bye processor and all the
memory
is manage by MMU and so paging...
------------------------------
** 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
******************************
