Linux-Development-Sys Digest #131, Volume #8 Fri, 8 Sep 00 15:13:18 EDT
Contents:
Re: printk output in X? (Bill Waddington)
Re: buffer_dirty - what's the @#$%? ("Ian Dichkovsky")
arp questions (L Stewart)
Re: buffer_dirty - what's the @#$%? (PoD)
OFF_T and 64bit Qustation?? ("Sean Oh")
Re: OFF_T and 64bit Qustation?? ("Sean Oh")
Re: OFF_T and 64bit Qustation?? ("Lawrence K. Chen, P.Eng.")
Re: arp questions ("Lawrence K. Chen, P.Eng.")
Re: Problem with fopen under RedHat 6.2 (Erik Max Francis)
Re: help with init (Miquel van Smoorenburg)
Re: OFF_T and 64bit Qustation?? (Miquel van Smoorenburg)
Re: buffer_dirty - what's the @#$%? (Rick Ellis)
Re: buffer_dirty - what's the @#$%? (Rick Ellis)
Re: OFF_T and 64bit Qustation?? ("Sean Oh")
Re: OFF_T and 64bit Qustation?? ("Sean Oh")
Re: buffer_dirty - what's the @#$%? (Ken Walter)
----------------------------------------------------------------------------
From: Bill Waddington <[EMAIL PROTECTED]>
Subject: Re: printk output in X?
Date: Fri, 08 Sep 2000 14:48:01 GMT
In article <[EMAIL PROTECTED]>,
Tasos Kotaras <[EMAIL PROTECTED]> wrote:
> Hello everybody,
>
> This is a newbie question, as I have just started meddling with
Linux
>
> device drivers: I have a problem getting output from printk while I'm
> in KDE. Of course, while I'm in in text mode everything works OK.
>
> I know that X 'covers' the virtual terminal which displays the
> messages,
> but I wonder why even the good-old 'xterm -C' doesn't do the trick...
>
> Is there anything I can do to get the printk output displayed while
I'm
> in X?
>
> I would be grateful for any help.
>
xterm -e tail -f /var/log/messages
(thanks Peter and Mario),
Bill
--
Bill Waddington
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Sent via Deja.com http://www.deja.com/
Before you buy.
------------------------------
From: "Ian Dichkovsky" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: buffer_dirty - what's the @#$%?
Date: Fri, 8 Sep 2000 18:04:23 +0300
Thanks, guys !
------------------------------
From: L Stewart <[EMAIL PROTECTED]>
Subject: arp questions
Date: 8 Sep 2000 15:38:59 GMT
I've got a couple of questions relating to ARP. First of all, I would like
to be able, in a user-space program, to ask the kernel to do an ARP lookup
for an IP address. Is there any way to do this? The SIOCGARP ioctl seems
to return a MAC address only if the related IP address is in the table..
(Yes, I can get around this by playing with libnet/pcap or packet sockets,
but just asking the kernel do something seems easier.)
Also, does anybody know of any decent documentation on the netlink
interface to the ARP cache? Thanks,
Liam
--
Liam Stewart
E-Mail: [EMAIL PROTECTED]
Web: http://ugweb.cs.ualberta.ca/~liam
Forty-two
-- Douglas Adams, "The Hitchhikers' Guide To The Galaxy"
------------------------------
From: PoD <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: buffer_dirty - what's the @#$%?
Date: Sat, 09 Sep 2000 01:48:07 +0930
[EMAIL PROTECTED] wrote:
>
> In comp.os.linux.misc Ian Dichkovsky <[EMAIL PROTECTED]> wrote:
> > 1. insert floppy
> > 2. mount floppy
> > 3. copy from floppy
> > 4. umount floppy
> > 5. remove floppy
>
> Linux caches its writes. The copy from floppy may not be complete unless
> you wait after step 3. Also, the programme may try to write to the floppy
> to update the time stamp (indicating the last time the file on the floppy
> was accessed) (if you interrupt it while it is writing to the fat
> sector(s) on the floppy, it will probably not just be a bad time stamp)
> and if you interrupt while it is writing to the floppy the record on the
> floppy may be faulty.
>
> After step 3 you can wait.
> After step 3 you can force a buffer write using "sync"
>
> Mounting the floppy as read only (which was another suggestion) should
> prevent the system from trying to update the floppy record (if you are
> copying from the floppy instead of to it and as long as the file is
> completely read into memory it can later write to the hard disk).
>
> On a system which caches writes you cannot just give a write command and
> remove the media (and copying from a read/write floppy may involve a write
> command to update the last access time). You have to ensure that the
> command is finished.
>
> A dirty buffer message indicates an incomplete result.
Shouldn't umount automatically sync before it exits?
------------------------------
From: "Sean Oh" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: OFF_T and 64bit Qustation??
Date: Sat, 9 Sep 2000 01:30:35 +0900
Well.. I am testing the 64 bit file access with Linux Kernel 2.2.16(RedHat
6.2)
Here is the test code..
#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
int main()
{
off_t r;
int fd;
printf("sizeof off_t= %d\n", sizeof(off_t));
fd = open("/dev/hda8", O_RDONLY, 0600);
r = lseek(fd, 0x0100000000, SEEK_SET);
printf("returned = 0x%x\n", r);
close(fd);
}
Well, /dev/hda8 is about 3GB. and I am testing whether lseek can access the
region over 2G limit. off_t is 4bytes by default so it can not access the
part 0x0100000000. So there has to be a certain option to make off_t to
off64_t.
Anyway, I tried with "gcc -o large large.c -D__USE_FILE_OFFSET64" and it
still shows sizeof(off_t) to 4bytes and "returned = 0".
Is there any other way to make off_t 64bit and lseek work the way as I want.
Thanks in advance and please replay via EMAIL: [EMAIL PROTECTED]
------------------------------
From: "Sean Oh" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation??
Date: Sat, 9 Sep 2000 02:17:26 +0900
Well.. here is more information regarding this question.
#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
int main()
{
int i;
off_t r;
int fd;
char * pw;
printf("sizeof off_t= %d\n", sizeof(off_t));
fd = open("/dev/hda8", O_RDONLY, 0600);
r = lseek(fd, 0x100000000, SEEK_SET);
pw = &r;
printf("returned = 0x%x %d\n", r,r);
for (i =0; i< 8 ; i++)
printf("%02x ", *pw ++);
printf("\n");
close(fd);
}
# gcc large.c -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64
# ./a.out
sizeof off_t= 8
returned = 0x0 1
00 00 00 00 01 00 00 00
Mmm... very strange results..
If I run this test program under Solaris 2.6 with -D_FILE_OFFSET_BITS=64, I
got:
# ./a.out
sizeof off_t= 8
returned = 0x1 0
00 00 00 01 00 00 00 00
BTW, off_t 64bit support on Solaris 2.6 is known to be broken.( printf will
not work)
What I want is "returned = 0x0100000000" (return off_t value for lseek on
success)
Any help will be greatly appreciated...
"Sean Oh" <[EMAIL PROTECTED]> wrote in message
news:Fw8u5.3$[EMAIL PROTECTED]...
>
> Well.. I am testing the 64 bit file access with Linux Kernel 2.2.16(RedHat
> 6.2)
>
> Here is the test code..
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <fcntl.h>
> #include <unistd.h>
>
> int main()
> {
> off_t r;
> int fd;
>
> printf("sizeof off_t= %d\n", sizeof(off_t));
> fd = open("/dev/hda8", O_RDONLY, 0600);
> r = lseek(fd, 0x0100000000, SEEK_SET);
> printf("returned = 0x%x\n", r);
>
> close(fd);
> }
>
>
> Well, /dev/hda8 is about 3GB. and I am testing whether lseek can access
the
> region over 2G limit. off_t is 4bytes by default so it can not access the
> part 0x0100000000. So there has to be a certain option to make off_t to
> off64_t.
>
> Anyway, I tried with "gcc -o large large.c -D__USE_FILE_OFFSET64" and it
> still shows sizeof(off_t) to 4bytes and "returned = 0".
>
> Is there any other way to make off_t 64bit and lseek work the way as I
want.
>
> Thanks in advance and please replay via EMAIL: [EMAIL PROTECTED]
>
>
>
>
------------------------------
From: "Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation??
Date: Fri, 08 Sep 2000 13:37:48 -0400
On Solaris, the correct way to compile for LARGE FILE support is something
like:
cc `getconf LFS_CFLAGS` -o prog prog.c
`getconf LFS_CFLAGS` returns "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
The last define changes the size of off_t, but its the first one that remaps
the various functions like lseek to use lseek64.
OTOH, if you want to mix 32bit and 64bit file access, you should use `getconf
LFS64_CFLAGS`....which returns "-D_LARGEFILE64_SOURCE".
So, if you use "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" on Linux, then
what your trying to do should work.
FWIW, I just tried printf() of a 64-bit off_t on Solaris 2.6 and it worked
fine. Your using "%lld", right?
Sean Oh wrote:
>
> Well.. here is more information regarding this question.
>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <fcntl.h>
> #include <unistd.h>
>
> int main()
> {
> int i;
> off_t r;
> int fd;
> char * pw;
>
> printf("sizeof off_t= %d\n", sizeof(off_t));
> fd = open("/dev/hda8", O_RDONLY, 0600);
> r = lseek(fd, 0x100000000, SEEK_SET);
> pw = &r;
> printf("returned = 0x%x %d\n", r,r);
> for (i =0; i< 8 ; i++)
> printf("%02x ", *pw ++);
> printf("\n");
>
> close(fd);
> }
> # gcc large.c -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64
> # ./a.out
>
> sizeof off_t= 8
> returned = 0x0 1
> 00 00 00 00 01 00 00 00
>
> Mmm... very strange results..
>
> If I run this test program under Solaris 2.6 with -D_FILE_OFFSET_BITS=64, I
> got:
>
> # ./a.out
> sizeof off_t= 8
> returned = 0x1 0
> 00 00 00 01 00 00 00 00
>
> BTW, off_t 64bit support on Solaris 2.6 is known to be broken.( printf will
> not work)
>
> What I want is "returned = 0x0100000000" (return off_t value for lseek on
> success)
> Any help will be greatly appreciated...
>
> "Sean Oh" <[EMAIL PROTECTED]> wrote in message
> news:Fw8u5.3$[EMAIL PROTECTED]...
> >
> > Well.. I am testing the 64 bit file access with Linux Kernel 2.2.16(RedHat
> > 6.2)
> >
> > Here is the test code..
> >
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <fcntl.h>
> > #include <unistd.h>
> >
> > int main()
> > {
> > off_t r;
> > int fd;
> >
> > printf("sizeof off_t= %d\n", sizeof(off_t));
> > fd = open("/dev/hda8", O_RDONLY, 0600);
> > r = lseek(fd, 0x0100000000, SEEK_SET);
> > printf("returned = 0x%x\n", r);
> >
> > close(fd);
> > }
> >
> >
> > Well, /dev/hda8 is about 3GB. and I am testing whether lseek can access
> the
> > region over 2G limit. off_t is 4bytes by default so it can not access the
> > part 0x0100000000. So there has to be a certain option to make off_t to
> > off64_t.
> >
> > Anyway, I tried with "gcc -o large large.c -D__USE_FILE_OFFSET64" and it
> > still shows sizeof(off_t) to 4bytes and "returned = 0".
> >
> > Is there any other way to make off_t 64bit and lseek work the way as I
> want.
> >
> > Thanks in advance and please replay via EMAIL: [EMAIL PROTECTED]
> >
> >
> >
> >
--
Snail: Lawrence K. Chen Email: [EMAIL PROTECTED]
4411 Camden Circle URL 1: http://www.bigfoot.com/~TheDreamer/
Dublin, OH 43016-3553 URL 2: http://members.xoom.com/TheDreamer/
Phone: 614-791-2130 Fax: 614-792-7544 ICQ: 5235156
------------------------------
From: "Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]>
Subject: Re: arp questions
Date: Fri, 08 Sep 2000 13:46:09 -0400
If its not currently in the ARP table, then do something that causes the
system to request it. Like open a socket to the machine.
L Stewart wrote:
>
> I've got a couple of questions relating to ARP. First of all, I would like
> to be able, in a user-space program, to ask the kernel to do an ARP lookup
> for an IP address. Is there any way to do this? The SIOCGARP ioctl seems
> to return a MAC address only if the related IP address is in the table..
> (Yes, I can get around this by playing with libnet/pcap or packet sockets,
> but just asking the kernel do something seems easier.)
>
> Also, does anybody know of any decent documentation on the netlink
> interface to the ARP cache? Thanks,
>
> Liam
>
> --
> Liam Stewart
> E-Mail: [EMAIL PROTECTED]
> Web: http://ugweb.cs.ualberta.ca/~liam
>
> Forty-two
> -- Douglas Adams, "The Hitchhikers' Guide To The Galaxy"
--
Snail: Lawrence K. Chen Email: [EMAIL PROTECTED]
4411 Camden Circle URL 1: http://www.bigfoot.com/~TheDreamer/
Dublin, OH 43016-3553 URL 2: http://members.xoom.com/TheDreamer/
Phone: 614-791-2130 Fax: 614-792-7544 ICQ: 5235156
------------------------------
From: Erik Max Francis <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Problem with fopen under RedHat 6.2
Date: Fri, 08 Sep 2000 10:46:00 -0700
Doug Dodson wrote:
> We are trying to port some code over to a Linux PC running RedHat 6.2.
> Compilation of the code is fine, however when we run, we get a
> segmentation fault on one of our fopen calls. We seem to be able to
> pass through the code once, but on the second iteration, we get the
> fault.
If you look at the traceback, it's crashing inside malloc. This almost
always means you have some memory error, such as free'ing memory that
wasn't malloc'ed, or double free'ing memory, or running past the end of
a malloc'ed array.
--
Erik Max Francis / [EMAIL PROTECTED] / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ If you can't fight and you can't flee, flow.
\__/ Robert Elliot
Product's Quake III Arena Tips / http://www.bosskey.net/
Tips and tricks from the beginning to the Arena Master.
------------------------------
From: [EMAIL PROTECTED] (Miquel van Smoorenburg)
Subject: Re: help with init
Date: 8 Sep 2000 17:48:26 GMT
In article <[EMAIL PROTECTED]>,
Marble Head <[EMAIL PROTECTED]> wrote:
>Can anybody tell me why the kernel would panic, saying
> "Kernel panic: No init found. Try passing init= option to kernel."
>(Don't tell me there's no init. Read on.)
>
>sdb5 I want to set up for a minimal boot. contains copies of the
>following
>directories from sdb1:
> /bin delete everything but sh, a copy of (not lnk to) bash.
> /dev delete everything but console, fd?, initctl, sda*, sdb*, tty?
> /etc delete everything but inittab
> /sbin delete nothing
> /usr /var /tmp /home were entirely discarded.
And what about /lib ?
Mike.
------------------------------
From: [EMAIL PROTECTED] (Miquel van Smoorenburg)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation??
Date: 8 Sep 2000 17:49:41 GMT
In article <Fw8u5.3$[EMAIL PROTECTED]>,
Sean Oh <[EMAIL PROTECTED]> wrote:
>Well.. I am testing the 64 bit file access with Linux Kernel 2.2.16(RedHat
>6.2)
The standard 2.2.16 kernel has no 64 bit LFS support.
Mike.
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: buffer_dirty - what's the @#$%?
Date: 8 Sep 2000 18:12:47 GMT
In article <8pa5j5$mr5$[EMAIL PROTECTED]>,
Robert Kaiser <[EMAIL PROTECTED]> wrote:
>> mount /mnt/fd; cp /mnt/fd/* /prj; umount /mnt/fd
>Even if you only read from floppy, depending on the filesystem type,
>the system may be trying to update access time entries.
>
>Try mounting the floppy read-only.
It shouldn't matter since the umount will flush the buffers.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: buffer_dirty - what's the @#$%?
Date: 8 Sep 2000 18:14:49 GMT
In article <39b8e7f0$[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> wrote:
>> 1. insert floppy
>> 2. mount floppy
>> 3. copy from floppy
>> 4. umount floppy
>> 5. remove floppy
>Linux caches its writes. The copy from floppy may not be complete unless
>you wait after step 3. Also, the programme may try to write to the floppy
>to update the time stamp (indicating the last time the file on the floppy
>was accessed) (if you interrupt it while it is writing to the fat
>sector(s) on the floppy, it will probably not just be a bad time stamp)
>and if you interrupt while it is writing to the floppy the record on the
>floppy may be faulty.
>
>After step 3 you can wait.
>After step 3 you can force a buffer write using "sync"
>
>Mounting the floppy as read only (which was another suggestion) should
>prevent the system from trying to update the floppy record (if you are
>copying from the floppy instead of to it and as long as the file is
>completely read into memory it can later write to the hard disk).
>
>On a system which caches writes you cannot just give a write command and
>remove the media (and copying from a read/write floppy may involve a write
>command to update the last access time). You have to ensure that the
>command is finished.
>
>A dirty buffer message indicates an incomplete result.
But there's no reason for a buffer to be dirty after umount returns.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: "Sean Oh" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation??
Date: Sat, 9 Sep 2000 03:24:12 +0900
Well.. this is what I did on Solaris 2.6 after reading your message..
ok.. the source file is the same except this time I put %lld instead %d.
# cc `getconf LFS_CFLAGS` oh.c
oh.c: In function `main':
oh.c:18: warning: assignment from incompatible pointer type
]# ./a.out
sizeof off_t= 8
returned = 0x1 1
00 00 00 01 00 00 00 00
Wrong result again..
On Linux, after compiling the test code
with -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64:
# gcc 2g.c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
2g.c: In function `main':
2g.c:18: warning: assignment from incompatible pointer type
# ./a.out
sizeof off_t= 8
returned = 0x0 1
00 00 00 00 01 00 00 00
Again.. Wrong result..
Please help...
"Lawrence K. Chen, P.Eng." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Solaris, the correct way to compile for LARGE FILE support is something
> like:
>
> cc `getconf LFS_CFLAGS` -o prog prog.c
>
> `getconf LFS_CFLAGS` returns "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64"
>
> The last define changes the size of off_t, but its the first one that
remaps
> the various functions like lseek to use lseek64.
>
> OTOH, if you want to mix 32bit and 64bit file access, you should use
`getconf
> LFS64_CFLAGS`....which returns "-D_LARGEFILE64_SOURCE".
>
> So, if you use "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" on Linux, then
> what your trying to do should work.
>
> FWIW, I just tried printf() of a 64-bit off_t on Solaris 2.6 and it worked
> fine. Your using "%lld", right?
>
> Sean Oh wrote:
> >
> > Well.. here is more information regarding this question.
> >
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <fcntl.h>
> > #include <unistd.h>
> >
> > int main()
> > {
> > int i;
> > off_t r;
> > int fd;
> > char * pw;
> >
> > printf("sizeof off_t= %d\n", sizeof(off_t));
> > fd = open("/dev/hda8", O_RDONLY, 0600);
> > r = lseek(fd, 0x100000000, SEEK_SET);
> > pw = &r;
> > printf("returned = 0x%x %d\n", r,r);
> > for (i =0; i< 8 ; i++)
> > printf("%02x ", *pw ++);
> > printf("\n");
> >
> > close(fd);
> > }
> > # gcc large.c -D_FILE_OFFSET_BITS=64 -D__USE_FILE_OFFSET64
> > # ./a.out
> >
> > sizeof off_t= 8
> > returned = 0x0 1
> > 00 00 00 00 01 00 00 00
> >
> > Mmm... very strange results..
> >
> > If I run this test program under Solaris 2.6
with -D_FILE_OFFSET_BITS=64, I
> > got:
> >
> > # ./a.out
> > sizeof off_t= 8
> > returned = 0x1 0
> > 00 00 00 01 00 00 00 00
> >
> > BTW, off_t 64bit support on Solaris 2.6 is known to be broken.( printf
will
> > not work)
> >
> > What I want is "returned = 0x0100000000" (return off_t value for lseek
on
> > success)
> > Any help will be greatly appreciated...
> >
> > "Sean Oh" <[EMAIL PROTECTED]> wrote in message
> > news:Fw8u5.3$[EMAIL PROTECTED]...
> > >
> > > Well.. I am testing the 64 bit file access with Linux Kernel
2.2.16(RedHat
> > > 6.2)
> > >
> > > Here is the test code..
> > >
> > > #include <sys/types.h>
> > > #include <sys/stat.h>
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <fcntl.h>
> > > #include <unistd.h>
> > >
> > > int main()
> > > {
> > > off_t r;
> > > int fd;
> > >
> > > printf("sizeof off_t= %d\n", sizeof(off_t));
> > > fd = open("/dev/hda8", O_RDONLY, 0600);
> > > r = lseek(fd, 0x0100000000, SEEK_SET);
> > > printf("returned = 0x%x\n", r);
> > >
> > > close(fd);
> > > }
> > >
> > >
> > > Well, /dev/hda8 is about 3GB. and I am testing whether lseek can
access
> > the
> > > region over 2G limit. off_t is 4bytes by default so it can not access
the
> > > part 0x0100000000. So there has to be a certain option to make off_t
to
> > > off64_t.
> > >
> > > Anyway, I tried with "gcc -o large large.c -D__USE_FILE_OFFSET64" and
it
> > > still shows sizeof(off_t) to 4bytes and "returned = 0".
> > >
> > > Is there any other way to make off_t 64bit and lseek work the way as I
> > want.
> > >
> > > Thanks in advance and please replay via EMAIL: [EMAIL PROTECTED]
> > >
> > >
> > >
> > >
>
> --
> Snail: Lawrence K. Chen Email: [EMAIL PROTECTED]
> 4411 Camden Circle URL 1:
http://www.bigfoot.com/~TheDreamer/
> Dublin, OH 43016-3553 URL 2:
http://members.xoom.com/TheDreamer/
> Phone: 614-791-2130 Fax: 614-792-7544 ICQ:
5235156
------------------------------
From: "Sean Oh" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.portable
Subject: Re: OFF_T and 64bit Qustation??
Date: Sat, 9 Sep 2000 03:25:06 +0900
Then, is there patch for making 64bit LFS support??
"Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote in message
news:8pb8rl$8fp$[EMAIL PROTECTED]...
> In article <Fw8u5.3$[EMAIL PROTECTED]>,
> Sean Oh <[EMAIL PROTECTED]> wrote:
> >Well.. I am testing the 64 bit file access with Linux Kernel
2.2.16(RedHat
> >6.2)
>
> The standard 2.2.16 kernel has no 64 bit LFS support.
>
> Mike.
------------------------------
From: [EMAIL PROTECTED] (Ken Walter)
Crossposted-To: comp.os.linux.hardware,comp.os.linux.misc,comp.os.linux.questions
Subject: Re: buffer_dirty - what's the @#$%?
Date: Fri, 08 Sep 2000 18:45:01 GMT
On Sun, 9 Sep 2000 01:48:07, PoD <[EMAIL PROTECTED]> wrote:
#[EMAIL PROTECTED] wrote:
#>
#> In comp.os.linux.misc Ian Dichkovsky <[EMAIL PROTECTED]> wrote:
#> > 1. insert floppy
#> > 2. mount floppy
#> > 3. copy from floppy
#> > 4. umount floppy
#> > 5. remove floppy
#>
#> Linux caches its writes. The copy from floppy may not be complete unless
#> you wait after step 3. Also, the programme may try to write to the floppy
#> to update the time stamp (indicating the last time the file on the floppy
#> was accessed) (if you interrupt it while it is writing to the fat
#> sector(s) on the floppy, it will probably not just be a bad time stamp)
#> and if you interrupt while it is writing to the floppy the record on the
#> floppy may be faulty.
#>
#> After step 3 you can wait.
#> After step 3 you can force a buffer write using "sync"
#>
#> Mounting the floppy as read only (which was another suggestion) should
#> prevent the system from trying to update the floppy record (if you are
#> copying from the floppy instead of to it and as long as the file is
#> completely read into memory it can later write to the hard disk).
#>
#> On a system which caches writes you cannot just give a write command and
#> remove the media (and copying from a read/write floppy may involve a write
#> command to update the last access time). You have to ensure that the
#> command is finished.
#>
#> A dirty buffer message indicates an incomplete result.
#
#Shouldn't umount automatically sync before it exits?
In a properly designed file system, caches should be written out
to removable media as quickly as possible. If the user manages
to remove the media before everything is written, the system should
request the media be reinserted and then finish.
Otherwise the removal should be an automatic dismount.
Anything else is user unfriendly.
Ken Walter
Remove -zamboni to reply
All the above is hearsay and the opinion of no one in particular
------------------------------
** 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
******************************
