Trond Myklebust writes:
> >>>>> " " == Albert D Cahalan <[EMAIL PROTECTED]> writes:
>> It would not be reasonable to try extending ext2 to 64-bit
>> times, but milliseconds might be doable. You'd need 4 bytes to
>> support the 3 standard time
Trond Myklebust writes:
> Relying on the sub-second timing fields is a much more
> implementation-specific. It depends on the capabilities of both the
> filesystem and the server OS.
> Linux and the knfsd server code could easily be modified to provide
> such a service, but the problem (as I've
Trond Myklebust writes:
Relying on the sub-second timing fields is a much more
implementation-specific. It depends on the capabilities of both the
filesystem and the server OS.
Linux and the knfsd server code could easily be modified to provide
such a service, but the problem (as I've
Alan Cox writes:
>> Over on the freebsd-questions mailing list you can see desperate
>> people trying to convert Linux systems over to that other OS to
>> escape Linux 2.2.xx NFS. This is kind of serious, you know?
>
> Shrug. So you want me to make it worse by shipping unproven code
> in a way I
David Howells writes:
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>> We already handle doing iBCS and Solaris syscalls by trapping int 7 and
>> int 0x27 insns and using a dedicated syscall handler - it doesn't go
>> anywhere near the original Linux syscall table.
>
> I was planning on having
David Howells writes:
David Woodhouse [EMAIL PROTECTED] wrote:
We already handle doing iBCS and Solaris syscalls by trapping int 7 and
int 0x27 insns and using a dedicated syscall handler - it doesn't go
anywhere near the original Linux syscall table.
I was planning on having using a
Alan Cox writes:
Over on the freebsd-questions mailing list you can see desperate
people trying to convert Linux systems over to that other OS to
escape Linux 2.2.xx NFS. This is kind of serious, you know?
Shrug. So you want me to make it worse by shipping unproven code
in a way I can't
David S. Miller writes:
> From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
>> Over on the freebsd-questions mailing list you can see desperate
>> people trying to convert Linux systems over to that other OS to
>> escape Linux 2.2.xx NFS. This is kind o
Alan Cox writes:
> [somebody]
>> Alan, are the NFS client/server patches EVER going to
>> make it into the base kernel? Inquiring minds want to know..
>
> I still hope so but there is a maximum sane rate of change and
> its important to change stuff piece by piece. 2.2.18pre4 isnt
> the right
Alan Cox writes:
[somebody]
sigh.. Alan, are the NFS client/server patches EVER going to
make it into the base kernel? Inquiring minds want to know..
I still hope so but there is a maximum sane rate of change and
its important to change stuff piece by piece. 2.2.18pre4 isnt
the right
David S. Miller writes:
From: "Albert D. Cahalan" [EMAIL PROTECTED]
Over on the freebsd-questions mailing list you can see desperate
people trying to convert Linux systems over to that other OS to
escape Linux 2.2.xx NFS. This is kind of serious, you know?
So basically the
Ragnar Hojland Esp writes:
> On Fri, Sep 08, 2000 at 11:10:13PM +0200, Kurt Garloff wrote:
> > Stop making stupid statements like this, please, and comparing well-d=
> efined
> > RFC standards with proprietary formats.=20
> > MIME is a way for people that happen to use non 7bit characters to be=
David S. Miller writes:
>From: Ulrich Kiermayr <[EMAIL PROTECTED]>
>
> Reserved: 6 bits
>
> Reserved for future use. Must be zero.
>
>
>The point is: 'must be zero' is redefined by rfc2481 (ECN).
>
> The authors of rfc793 probably, in all honesty, really meant
>
Ragnar Hojland Esp writes:
On Fri, Sep 08, 2000 at 11:10:13PM +0200, Kurt Garloff wrote:
Stop making stupid statements like this, please, and comparing well-d=
efined
RFC standards with proprietary formats.=20
MIME is a way for people that happen to use non 7bit characters to be=
able
David S. Miller writes:
From: Ulrich Kiermayr [EMAIL PROTECTED]
quote
Reserved: 6 bits
Reserved for future use. Must be zero.
/quote
The point is: 'must be zero' is redefined by rfc2481 (ECN).
The authors of rfc793 probably, in all honesty, really meant
David Howells writes:
> I've done an implementation of some of the Win32 "system calls"
> in a kernel module in an attempt to speed up Wine.
Oh my. How dare you! I like it. :-)
> The preliminary benchmarks that I made, while not very real-world
> since I don't think I have managed to implement
David Howells writes:
I've done an implementation of some of the Win32 "system calls"
in a kernel module in an attempt to speed up Wine.
Oh my. How dare you! I like it. :-)
The preliminary benchmarks that I made, while not very real-world
since I don't think I have managed to implement
Alan Cox writes:
> [somebody]
>> Excuse me? How the hell do you expect them to "clean up their act" when
>> their "dialup" users are the problem? Are you gonna scan 250,000 machines
>> to make sure they aren't running SMTP servers? Trap all port 25 traffic?
>
> FreeServe in the UK have over 3
Jorge Nerin writes:
> Neal H Walfield wrote:
>> Starting twelve days ago the load average has increased by one every
>> twenty-four hours. Normally, it remains close to 0. At the moment, they
>> are at twelve; I imagine that tomorrow, they will be at thirteen:
> You may have stuck processes
Rik van Riel writes:
> On Mon, 4 Sep 2000, Stephen C. Tweedie wrote:
>> On Fri, Sep 01, 2000 at 09:16:23AM -0700, Linda Walsh wrote:
>>> With all the talk about bugs and slowness on a 386/486/586
>>> -- does anyone think those platforms will have multi-T disks
>>> hooked up to them?
Note: no
Rik van Riel writes:
On Mon, 4 Sep 2000, Stephen C. Tweedie wrote:
On Fri, Sep 01, 2000 at 09:16:23AM -0700, Linda Walsh wrote:
With all the talk about bugs and slowness on a 386/486/586
-- does anyone think those platforms will have multi-T disks
hooked up to them?
Note: no "686"
Jorge Nerin writes:
Neal H Walfield wrote:
Starting twelve days ago the load average has increased by one every
twenty-four hours. Normally, it remains close to 0. At the moment, they
are at twelve; I imagine that tomorrow, they will be at thirteen:
You may have stuck processes wich
Alan Cox writes:
[somebody]
Excuse me? How the hell do you expect them to "clean up their act" when
their "dialup" users are the problem? Are you gonna scan 250,000 machines
to make sure they aren't running SMTP servers? Trap all port 25 traffic?
FreeServe in the UK have over 3 million
Alan Cox writes:
>> What is the deal here? I have NEVER seen anyboody flatly refuse email
>> from me. Are you telling me I have to go into work and use my
>> [EMAIL PROTECTED] email address to talk to Alan? That's asinine.
>
> When you get as much spam aimed at you as I do because the address
>
Alan Cox writes:
What is the deal here? I have NEVER seen anyboody flatly refuse email
from me. Are you telling me I have to go into work and use my
[EMAIL PROTECTED] email address to talk to Alan? That's asinine.
When you get as much spam aimed at you as I do because the address
is so
Alan Cox writes:
> o Make vfat use the same generation rules as (H. Kawaguchi,
> in windows 9xChip Salzenberg)
I doubt this is obviously correct. The last time this issue
came up, it was discovered that Windows 9x does not use the
same
> address 68736170
> address 33312051
> address 3331203d
The kernel is using ASCII text as pointers. Convert the above:
"pash"
"Q 13"
"= 13"
Try different kernels and different compilers.
The hardware is probably OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
address 68736170
address 33312051
address 3331203d
The kernel is using ASCII text as pointers. Convert the above:
"pash"
"Q 13"
"= 13"
Try different kernels and different compilers.
The hardware is probably OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Robert Greimel writes:
>> BTW, /boot/System.map-`uname -r` is the first place in which
>> procps looks for the the System.map data. Red Hat and Debian
>
> Yes, but it is no good if you switch between different kernel
> versions as you will get error messages about System.map being
> the wrong
Alan Cox writes:
>> where you overwrite your old kernel image with a new one without
>> rebooting instantly).
>>
>> But is it so much more expensive than a /proc/config.whatever ?
>
> Use that argument 50 times and your kernel has grown 100K.
If I get the same level of benefit 50 times,
Michael Elizabeth Chastain writes:
> I'm beginning to think that installation should copy everyting
> (bzImage, System.map, modules) into /lib/modules/. This split
> between resident and modules just causes endless hassle.
That would be a serious error. Often /boot is a special partition
Michael Elizabeth Chastain writes:
I'm beginning to think that installation should copy everyting
(bzImage, System.map, modules) into /lib/modules/release. This split
between resident and modules just causes endless hassle.
That would be a serious error. Often /boot is a special partition
Alan Cox writes:
where you overwrite your old kernel image with a new one without
rebooting instantly).
But is it so much more expensive than a /proc/config.whatever ?
Use that argument 50 times and your kernel has grown 100K.
If I get the same level of benefit 50 times, wonderful!
With
Robert Greimel writes:
BTW, /boot/System.map-`uname -r` is the first place in which
procps looks for the the System.map data. Red Hat and Debian
Yes, but it is no good if you switch between different kernel
versions as you will get error messages about System.map being
the wrong version
Alexander Viro writes:
> On Wed, 30 Aug 2000, Roman Zippel wrote:
>> The point is: the thing I like about Linux is its simple interfaces, it's
>> the basic idea of unix - keep it simple. That is true for most parts - the
>> basic idea is simple and the real complexity is hidden behind it. But
>>
David S. Miller writes:
> The problem not FASTCALL, which is a NOP on sparc anyways. The
> problem is the fact that people expect the following to work:
...
> And it doesn't on Sparc because the flags are stored in the same CPU
> register as the current register window.
>
> Therefore you
Alexander Viro writes:
> On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
[interaction w/ setuid, close-on-exec, and personality pseudo-roots]
> We _have_ this interaction. In case you've missed it, sys_personality()
> that really happens to change personality unshares fs_struct. Has t
Alexander Viro writes:
On Tue, 29 Aug 2000, Albert D. Cahalan wrote:
[interaction w/ setuid, close-on-exec, and personality pseudo-roots]
We _have_ this interaction. In case you've missed it, sys_personality()
that really happens to change personality unshares fs_struct. Has to.
Rule: you
David S. Miller writes:
The problem not FASTCALL, which is a NOP on sparc anyways. The
problem is the fact that people expect the following to work:
...
And it doesn't on Sparc because the flags are stored in the same CPU
register as the current register window.
Therefore you cannot
401 - 439 of 439 matches
Mail list logo
