Derek Vadala writes:
> It's clear that under 2.4, the kernel imposes a limit of 2TB as the
> maximum file size and that some portion of the kernels before 2.4 had a
> limit of 2GB.
>
> However, it's not clear to me when the file size limit was increased, or
> what the maximum file system sizes
Rob Landley writes:
> Off the top of my head, fun things you can't do suid root:
...
> ps (What the...? Worked in Red Hat 7, but not in suse 7.1.
> Huh? "suid-to apache ps ax" works fine, though...)
The ps command used to require setuid root. People would set the
bit by habit.
> I keep
Wakko Warner writes:
> I believe there is. It wants to find what drive is bios drive 80h. Really
> annoying since there's no way (correct me if I'm wrong) to read bios from
> linux. If there is, lilo should do that. But since it's an old copy, this
> probably was fixed.
>
> I had a machine
Wakko Warner writes:
I believe there is. It wants to find what drive is bios drive 80h. Really
annoying since there's no way (correct me if I'm wrong) to read bios from
linux. If there is, lilo should do that. But since it's an old copy, this
probably was fixed.
I had a machine at work
Rob Landley writes:
Off the top of my head, fun things you can't do suid root:
...
ps (What the...? Worked in Red Hat 7, but not in suse 7.1.
Huh? suid-to apache ps ax works fine, though...)
The ps command used to require setuid root. People would set the
bit by habit.
I keep bumping
Derek Vadala writes:
It's clear that under 2.4, the kernel imposes a limit of 2TB as the
maximum file size and that some portion of the kernels before 2.4 had a
limit of 2GB.
However, it's not clear to me when the file size limit was increased, or
what the maximum file system sizes under
> Almost always ?
> It seems like gcc is THE ONLY program which gets
> signal 11
> Why the X server doesn't get signal 11 ?
> Why others programs don't get signal 11 ?
...
> Some time ago I installed Linux (Redhat 6.0) on my
> pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a
> couple every
Almost always ?
It seems like gcc is THE ONLY program which gets
signal 11
Why the X server doesn't get signal 11 ?
Why others programs don't get signal 11 ?
...
Some time ago I installed Linux (Redhat 6.0) on my
pc (Cx486 8M RAM) and gcc had a lot of signal 11 (a
couple every hour) I
Sean Hunter writes:
> On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
>> ln /dev/zero /tmp/zero
>> ln /dev/hda ~/hda
>> ln /dev/mem /var/tmp/README
>
> None of these (of course) work if you use mount options to
> restrict device nodes on those fi
Sean Hunter writes:
On Wed, Jun 27, 2001 at 04:55:56PM -0400, Albert D. Cahalan wrote:
ln /dev/zero /tmp/zero
ln /dev/hda ~/hda
ln /dev/mem /var/tmp/README
None of these (of course) work if you use mount options to
restrict device nodes on those filesystems.
In which case, you can't boot
H. Peter Anvin writes:
> "Albert D. Cahalan" wrote:
>> BTW, it is way wrong that /dev/zero should be needed at all.
>> Such use is undocumented ("man zero", "man mmap") anyway, and
>> AFAIK one should use mmap() with MAP_ANON instead. Not that
H. Peter Anvin writes:
> Albert D. Cahalan wrote:
>> Normal users can use an environment provided for them.
>>
>> While trying to figure out why the "heyu" program would not
>> work on a Red Hat box, I did just this. As root I set up all
>> the
H. Peter Anvin writes:
Albert D. Cahalan wrote:
Normal users can use an environment provided for them.
While trying to figure out why the heyu program would not
work on a Red Hat box, I did just this. As root I set up all
the device files needed, along Debian libraries and the heyu
H. Peter Anvin writes:
Albert D. Cahalan wrote:
BTW, it is way wrong that /dev/zero should be needed at all.
Such use is undocumented (man zero, man mmap) anyway, and
AFAIK one should use mmap() with MAP_ANON instead. Not that
the documentation on MAP_ANON is any good either, but at least
H. Peter Anvin writes:
> [somebody]
>> Have you ever wondered why normal users are not allowed to chroot?
>>
>> I have. The reasons I can figure out are:
>>
>> * Changing root makes it trivial to trick suid/sgid binaries to do
>> nasty things.
>>
>> * If root calls chroot and changes uid, he
Kenneth Johansson writes:
> Do linux even support the sticky bit (t) I can't see a reason
> to use it, why would I want the file to be stored in the swap ??
It is not currently supported. Swapping out executables would
be very nice when using an NFS or CD-ROM filesystem, because
swap space is
Kenneth Johansson writes:
Do linux even support the sticky bit (t) I can't see a reason
to use it, why would I want the file to be stored in the swap ??
It is not currently supported. Swapping out executables would
be very nice when using an NFS or CD-ROM filesystem, because
swap space is
H. Peter Anvin writes:
[somebody]
Have you ever wondered why normal users are not allowed to chroot?
I have. The reasons I can figure out are:
* Changing root makes it trivial to trick suid/sgid binaries to do
nasty things.
* If root calls chroot and changes uid, he expects that the
Daniel Phillips writes:
> On Monday 25 June 2001 00:54, Albert D. Cahalan wrote:
>> By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
>> as seen in Tux2. This means it offers full data integrity.
>> Yep, it whips your typical journalling filesystem. Lo
By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
as seen in Tux2. This means it offers full data integrity.
Yep, it whips your typical journalling filesystem. Look at what
we have in the superblock (boot sector):
__u32 fat32_length; /* sectors/FAT */
__u16 flags;
By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
as seen in Tux2. This means it offers full data integrity.
Yep, it whips your typical journalling filesystem. Look at what
we have in the superblock (boot sector):
__u32 fat32_length; /* sectors/FAT */
__u16 flags;
Daniel Phillips writes:
On Monday 25 June 2001 00:54, Albert D. Cahalan wrote:
By dumb luck (?), FAT32 is compatible with the phase-tree algorithm
as seen in Tux2. This means it offers full data integrity.
Yep, it whips your typical journalling filesystem. Look at what
we have
Allan Duncan writes:
> Since the 2.4.x advent of shm as tmpfs or thereabouts,
> /proc/meminfo shows shared memory as 0. It is in
> reality not zero, and is being allocated, and shows
> up in /proc/sysvipc/shm and /proc/sys/kernel/shmall
> etc..
> Neither 2.4.6-pre5 nor 2.4.5-ac17 have the
Allan Duncan writes:
Since the 2.4.x advent of shm as tmpfs or thereabouts,
/proc/meminfo shows shared memory as 0. It is in
reality not zero, and is being allocated, and shows
up in /proc/sysvipc/shm and /proc/sys/kernel/shmall
etc..
Neither 2.4.6-pre5 nor 2.4.5-ac17 have the correct
Alan Cox writes:
> [somebody]
>> I could not find any reference to BIOS int 0x15, function 0x87,
>> block-move, used to copy the kernel to above the 1 megabyte
>> real-mode boundary. I think this is still used.
>
> I dont think the kernel has ever used it. The path has always been to
> enter
Alan Cox writes:
[somebody]
I could not find any reference to BIOS int 0x15, function 0x87,
block-move, used to copy the kernel to above the 1 megabyte
real-mode boundary. I think this is still used.
I dont think the kernel has ever used it. The path has always been to
enter 32bit mode
Zach Brown writes:
> The attached patch-in-progress removes the per-cpu statistics from
> struct kernel_stat and puts them in a cpu_stat structure, one per cpu,
> cacheline padded. The data is still coolated and presented through
> /proc/stat, but another file /proc/cpustat is also added. The
Rob Landley writes:
> On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
>> Mike Harrold wrote:
>> super computing, hmm what about some PowerPC CPU variant - they very
>> compettetiv in terms of cost and FPU performance! Transmeta isn't the
>> adequate choice here.
>
> You honestly think you
Rob Landley writes:
On Wednesday 20 June 2001 15:53, Martin Dalecki wrote:
Mike Harrold wrote:
super computing, hmm what about some PowerPC CPU variant - they very
compettetiv in terms of cost and FPU performance! Transmeta isn't the
adequate choice here.
You honestly think you can fit
Zach Brown writes:
The attached patch-in-progress removes the per-cpu statistics from
struct kernel_stat and puts them in a cpu_stat structure, one per cpu,
cacheline padded. The data is still coolated and presented through
/proc/stat, but another file /proc/cpustat is also added. The
Rob Landley writes:
> My only real gripe with Linux's threads right now [...] is
> that ps and top and such aren't thread aware and don't group them
> right.
>
> I'm told they added some kind of "threadgroup" field to processes
> that allows top and ps and such to get the display right. I
Rob Landley writes:
My only real gripe with Linux's threads right now [...] is
that ps and top and such aren't thread aware and don't group them
right.
I'm told they added some kind of threadgroup field to processes
that allows top and ps and such to get the display right. I haven't
Pozsar Balazs writes:
> I'm having ~2 lockups a day. The following happens:
> If I was under X, i only can use the magic-key, but no other keyboard (eg
> numlock) or mouse response, the screen freezes, processes stop.
> If i was using textmode:
> numlock still works
> cursor blinks
>
Pozsar Balazs writes:
I'm having ~2 lockups a day. The following happens:
If I was under X, i only can use the magic-key, but no other keyboard (eg
numlock) or mouse response, the screen freezes, processes stop.
If i was using textmode:
numlock still works
cursor blinks
processess
Daniel Phillips writes:
> On Friday 15 June 2001 21:21, Albert D. Cahalan wrote:
>> Non-blinking cursors are just wrong. You need to patch your brain.
>> You really fucked up, because now apps can't restore your cursor
>> to proper behavior as defined by IBM.
>
> Ju
Leon Breedt writes:
> Attached is a patch to enforce a non-blinking, FreeBSD-syscons like
> block cursor in console mode.
>
> This is useful for laptop types, or people like me who really really
> detest a blinking cursor.
>
> NOTE: It disables the softcursor escape codes
>
Mike Black writes:
> I'm concerned that you're probably just overruning your IP stack:
...
> TCP is NOT a guaranteed protocol -- you can't just blast data from one port
> to another and expect it to work.
Yes you can. This is why we have TCP in fact.
> a tcp-write is NOT guaranteed -- and as
Mike Black writes:
I'm concerned that you're probably just overruning your IP stack:
...
TCP is NOT a guaranteed protocol -- you can't just blast data from one port
to another and expect it to work.
Yes you can. This is why we have TCP in fact.
a tcp-write is NOT guaranteed -- and as
Leon Breedt writes:
Attached is a patch to enforce a non-blinking, FreeBSD-syscons like
block cursor in console mode.
This is useful for laptop types, or people like me who really really
detest a blinking cursor.
NOTE: It disables the softcursor escape codes
Daniel Phillips writes:
On Friday 15 June 2001 21:21, Albert D. Cahalan wrote:
Non-blinking cursors are just wrong. You need to patch your brain.
You really fucked up, because now apps can't restore your cursor
to proper behavior as defined by IBM.
Just one question Albert: why doesn't my
David S. Miller writes:
> Jeff Garzik writes:
>> According to the PCI spec it is -impossible- to have more than 256
>> buses on a single "hose", so you simply have to implement multiple
>> hoses, just like Alpha (and Sparc64?) already do. That's how the
>> hardware is forced to implement it...
David S. Miller writes:
Jeff Garzik writes:
According to the PCI spec it is -impossible- to have more than 256
buses on a single hose, so you simply have to implement multiple
hoses, just like Alpha (and Sparc64?) already do. That's how the
hardware is forced to implement it...
Right,
Tom Gall writes:
> I was wondering if there are any other folks out there like me who
> have the 256 PCI bus limit looking at them straight in the face?
I might. The need to reserve bus numbers for hot-plug looks like
a quick way to waste all 256 bus numbers.
> each PHB has an
> additional
Tom Gall writes:
I was wondering if there are any other folks out there like me who
have the 256 PCI bus limit looking at them straight in the face?
I might. The need to reserve bus numbers for hot-plug looks like
a quick way to waste all 256 bus numbers.
each PHB has an
additional id,
Zehetbauer Thomas writes:
> Has someone experimented with running linux in little-endian mode on IBM
> PowerPC 405 (Walnut) yet?
I doubt it. You are at least the 3rd person to want little-endian.
Somebody at Matrox posted a patch for little-endian on the 74xx.
You need a bit more than that
Zehetbauer Thomas writes:
Has someone experimented with running linux in little-endian mode on IBM
PowerPC 405 (Walnut) yet?
I doubt it. You are at least the 3rd person to want little-endian.
Somebody at Matrox posted a patch for little-endian on the 74xx.
You need a bit more than that
Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only th
Struct padding is a problem. Really, there shouldn't be any
implicit padding. This causes:
1. security leaks when such structs are copied to userspace
(the implicit padding is uninitialized, and so may contain
a chunk of somebody's private key or password)
2. bloat, when struct members
Struct padding is a problem. Really, there shouldn't be any
implicit padding. This causes:
1. security leaks when such structs are copied to userspace
(the implicit padding is uninitialized, and so may contain
a chunk of somebody's private key or password)
2. bloat, when struct members
Michael H. Warfiel writes:
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
The bits are free; the API is hard to change.
Sensors might get better, at least on high-end systems.
Rounding gives a constant 0.15 degree error.
Only the truly stupid would assume accuracy from
Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only th
John Chris Wren writes:
> coupling to the CPU that is about as bad as it can get. You've got an epoxy
> housing of an inconsistent shape in contact with ceramic. The actual
> contact point is miniscule. There's no thermal paste, and often, I've seen
> the sensors not quite raised high enough
L. K. writes:
> On Fri, 8 Jun 2001, Albert D. Cahalan wrote:
>> The bits are free; the API is hard to change.
>> Sensors might get better, at least on high-end systems.
>> Rounding gives a constant 0.15 degree error.
>> Only the truly stupid would assume accuracy fr
Michael H. Warfiel writes:
> We don't have sensors that are accurate to 1/10 of a K and certainly not
> to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when
> the accuracy of the best sensor we are likely to see is no better than
> +- 1 K is just about as relevant as negative
Michael H. Warfiel writes:
We don't have sensors that are accurate to 1/10 of a K and certainly not
to 1/100 of a K. Knowing the CPU temperature precise to .01 K when
the accuracy of the best sensor we are likely to see is no better than
+- 1 K is just about as relevant as negative absolute
L. K. writes:
On Fri, 8 Jun 2001, Albert D. Cahalan wrote:
The bits are free; the API is hard to change.
Sensors might get better, at least on high-end systems.
Rounding gives a constant 0.15 degree error.
Only the truly stupid would assume accuracy from decimal places.
Again, the bits
John Chris Wren writes:
coupling to the CPU that is about as bad as it can get. You've got an epoxy
housing of an inconsistent shape in contact with ceramic. The actual
contact point is miniscule. There's no thermal paste, and often, I've seen
the sensors not quite raised high enough to
Michael H. Warfiel writes:
On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:
The bits are free; the API is hard to change.
Sensors might get better, at least on high-end systems.
Rounding gives a constant 0.15 degree error.
Only the truly stupid would assume accuracy from
Chris Boot writes:
Kelvins good idea in general - it is always positive ;-)
0.01*K fits in 16 bits and gives reasonable range.
...
> OK, I think by now we've all agreed the following:
> - The issue is NOT displaying temperatures to the user, but a userspace
>program reading
Jan Kasprzak writes:
> Another goal is to use the Linux filesystem
> as a backing store (as opposed to the block device or single large file
> used by CODA).
...
> - kernel module, implementing the filesystem of the type "cachefs"
> and a character device
L. K. writes:
> Why not make it in Celsius ? Is more easy to read it this way.
No, because then the software must handle negative numbers for
cooled computers. CentiKelvin is fine. Do C=cK/100-273.15 if you
really must... but you still have a number that is useless to
a human. Humans need a
L. K. writes:
Why not make it in Celsius ? Is more easy to read it this way.
No, because then the software must handle negative numbers for
cooled computers. CentiKelvin is fine. Do C=cK/100-273.15 if you
really must... but you still have a number that is useless to
a human. Humans need a
Jan Kasprzak writes:
Another goal is to use the Linux filesystem
as a backing store (as opposed to the block device or single large file
used by CODA).
...
- kernel module, implementing the filesystem of the type cachefs
and a character device /dev/cachefs
Chris Boot writes:
Kelvins good idea in general - it is always positive ;-)
0.01*K fits in 16 bits and gives reasonable range.
...
OK, I think by now we've all agreed the following:
- The issue is NOT displaying temperatures to the user, but a userspace
program reading them from the
David S. Miller writes:
> David Woodhouse writes:
>>> Call it flush_ecache_full() or something.
>>
>> Strange name. Why? How about __flush_cache_range()?
>
> How about flush_cache_range_force() instead?
>
> I want something in the name that tells the reader "this flushes
> the caches, even
Paul Mackerras writes:
> The only valid reason for userspace programs to be including kernel
> headers is to get definitions that are part of the kernel API. (And
> in fact others here will go further and assert that there are *no*
> valid reasons for userspace programs to include kernel
Paul Mackerras writes:
The only valid reason for userspace programs to be including kernel
headers is to get definitions that are part of the kernel API. (And
in fact others here will go further and assert that there are *no*
valid reasons for userspace programs to include kernel headers.)
David S. Miller writes:
David Woodhouse writes:
Call it flush_ecache_full() or something.
Strange name. Why? How about __flush_cache_range()?
How about flush_cache_range_force() instead?
I want something in the name that tells the reader this flushes
the caches, even though under every
Alexander Viro writes:
> leaves ncp with its ioctls ugliness.
Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole
Alexander Viro writes:
leaves ncp with its ioctls ugliness.
Authentication will be ugly. Joe mounts a filesystem, and does
not bother to authenticate. He gets world-accessible files.
Then Kevin authenticates as himself, and later as db_adm too.
Along comes Sue, who can authenticate the whole
[EMAIL PROTECTED] writes:
> This is probably an FAQ, but I read the FAQ and its not in there.
Odd.
> I have a machine with 2G of memory. I compiled the kernel with the
> 4G memory option. How much address space should each process be
> able to address?
3 GB for user stuff, or 3.5 GB with a
[EMAIL PROTECTED] writes:
This is probably an FAQ, but I read the FAQ and its not in there.
Odd.
I have a machine with 2G of memory. I compiled the kernel with the
4G memory option. How much address space should each process be
able to address?
3 GB for user stuff, or 3.5 GB with a
Harald Welte writes:
> Is there any way to read out the compile-time HZ value of the kernel?
>
> I had a brief look at /proc/* and didn't find anything.
Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.
Jonathan Lundell writes:
> At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
>>> If you now want to set those values from a userspace program / script in
>>> a portable manner, you need to be able to find out of HZ of the currently
>>> running kernel.
>>
>> Yes, but that's because the
Jonathan Lundell writes:
At 5:07 PM -0700 2001-05-30, H. Peter Anvin wrote:
If you now want to set those values from a userspace program / script in
a portable manner, you need to be able to find out of HZ of the currently
running kernel.
Yes, but that's because the interfaces are
Harald Welte writes:
Is there any way to read out the compile-time HZ value of the kernel?
I had a brief look at /proc/* and didn't find anything.
Look again, this time with a sick mind. Got your barf bag?
Kubys made me do it.
David S. Miller
> Ingo Molnar writes:
>> (unlike bottom halves, soft-IRQs do not preempt kernel code.)
> ...
>
> Since when do we have this rule? :-)
...
> You should check Softirqs on return from every single IRQ.
> In do_softirq() it will make sure that we won't run softirqs
> while already
David S. Miller
Ingo Molnar writes:
(unlike bottom halves, soft-IRQs do not preempt kernel code.)
...
Since when do we have this rule? :-)
...
You should check Softirqs on return from every single IRQ.
In do_softirq() it will make sure that we won't run softirqs
while already doing so or
Mark Hahn writes:
> contrary to the implication here, I don't believe there is any *general*
> problem with Linux/VIA/AMD stability. there are well-known issues
> with specific items (VIA 686b, for instance), but VIA/AMD hardware
> is quite suitable for servers.
VIA hardware is not suitable
Oliver Xymoron writes:
> The /dev dir should not be special. At least not to the kernel. I have
> device files in places other than /dev, and you probably do too (hint:
> anonymous FTP).
This is a horribly broken FTP server.
-
To unsubscribe from this list: send the line "unsubscribe
Mark Hahn writes:
contrary to the implication here, I don't believe there is any *general*
problem with Linux/VIA/AMD stability. there are well-known issues
with specific items (VIA 686b, for instance), but VIA/AMD hardware
is quite suitable for servers.
VIA hardware is not suitable for
Oliver Xymoron writes:
The /dev dir should not be special. At least not to the kernel. I have
device files in places other than /dev, and you probably do too (hint:
anonymous FTP).
This is a horribly broken FTP server.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
David S. Miller writes:
> What are these "devices", and what drivers "just program the cards to
> start the dma on those hundred mbyte of ram"?
Hmmm, I have a few cards that are used that way. They are used
for communication between nodes of a cluster.
One might put 16 cards in a system. The
David S. Miller writes:
What are these devices, and what drivers just program the cards to
start the dma on those hundred mbyte of ram?
Hmmm, I have a few cards that are used that way. They are used
for communication between nodes of a cluster.
One might put 16 cards in a system. The cards
Guest section DW writes:
> On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
>> The PC partition table has such an ID. The LILO change log
>> mentions it. I think it's 6 random bytes, with some restriction
>> about being non-zero.
>
> You are co
Guest section DW writes:
On Thu, May 17, 2001 at 02:35:55AM -0400, Albert D. Cahalan wrote:
The PC partition table has such an ID. The LILO change log
mentions it. I think it's 6 random bytes, with some restriction
about being non-zero.
You are confused. The partition table contains IDs
Bingner Sam J. Con writes:
> Looks to me like it's adding { and } on each side of the
> "c->devices->prev=d;" statement... so changing from:
>
> if (c->devices != NULL)
> c->devices->prev=d;
>
> to
>
> if (c->devices != NULL){
> c->devices->prev=d;
> }
>
> I assume the new
Heinz J. Mauelshag writes:
> LVM does a similar thing storing UUIDs in its private metadata
> area on every device used by it.
>
> Problem is: neither MD nor LVM define a standard in Linux
> which *needs* to be used on every device!
>
> It is just up to the user to configure devices with them or
Heinz J. Mauelshag writes:
LVM does a similar thing storing UUIDs in its private metadata
area on every device used by it.
Problem is: neither MD nor LVM define a standard in Linux
which *needs* to be used on every device!
It is just up to the user to configure devices with them or not.
Bingner Sam J. Con writes:
Looks to me like it's adding { and } on each side of the
c-devices-prev=d; statement... so changing from:
if (c-devices != NULL)
c-devices-prev=d;
to
if (c-devices != NULL){
c-devices-prev=d;
}
I assume the new compiler likes the if to
Jeff Garzik writes:
> "Khachaturov, Vassilii" wrote:
>> Can someone please confirm if my assumptions below are correct:
>> 1) Unless someone specifically tampered with my driver's device
>> since the OS bootup, the mapping of the PCI base address registers
>> to virtual memory will remain the
Jeff Garzik writes:
Khachaturov, Vassilii wrote:
Can someone please confirm if my assumptions below are correct:
1) Unless someone specifically tampered with my driver's device
since the OS bootup, the mapping of the PCI base address registers
to virtual memory will remain the same (just as
H. Peter Anvin writes:
> This would leave no way (without introducing new interfaces) to write,
> for example, the boot block on an ext2 filesystem. Note that the
> bootblock (defined as the first 1024 bytes) is not actually used by
> the filesystem, although depending on the block size it may
H. Peter Anvin writes:
This would leave no way (without introducing new interfaces) to write,
for example, the boot block on an ext2 filesystem. Note that the
bootblock (defined as the first 1024 bytes) is not actually used by
the filesystem, although depending on the block size it may
Daniel Phillips writes:
> On Monday 14 May 2001 07:29, Blesson Paul wrote:
>>I am trying to implement a distributed file system.
Me too! :-)
>> For that I write a file driver. I want to know the following things
>>
>> 1 . If I am writing a new file system, is it necessary to
Blesson Paul writes:
> This is an another doubt related to VFS. I want to know
> wheather all files are assigned their inode number at the
> mounting time itself or inodes are assigned to files upon
> accessing only
That would depend on what type of filesystem you use.
For ext2, inode numbers
Daniel Phillips writes:
On Monday 14 May 2001 07:29, Blesson Paul wrote:
I am trying to implement a distributed file system.
Me too! :-)
For that I write a file driver. I want to know the following things
1 . If I am writing a new file system, is it necessary to modify the
Hans Reiser writes:
> Tell us what to code for, and so long as it doesn't involve looking
> up files by their 32 bit inode numbers we'll probably be happy to
> code to it. The Neil Brown stuff is already coded for though.
Next time around, when you update the on-disk format, how about
allowing
Hans Reiser writes:
Tell us what to code for, and so long as it doesn't involve looking
up files by their 32 bit inode numbers we'll probably be happy to
code to it. The Neil Brown stuff is already coded for though.
Next time around, when you update the on-disk format, how about
allowing
Jeff Garzik writes:
> Pavel Roskin wrote:
>> You may need to save some data in memory when the system goes
>> to suspend and restore them afterwards. I believe that the PCI
>> config space should be saved by BIOS. Everything else is the
>> responsibility of the driver.
>
> In ACPI land the
1 - 100 of 439 matches
Mail list logo
