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 kernel should
Pete Zaitcev writes:
> Russel King complained that you might be calling pci_consistent_free
> from an interrupt, which is unsafe on ARM.
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where
Pierre Rousselet writes:
> James Bourne wrote:
>> From the procps man page:
>>Albert Cahalan <[EMAIL PROTECTED]> rewrote ps for full
>>Unix98 and BSD support, along with some ugly hacks for
>>obsolete and foreign syntax.
>>
>>Michael K. Johnson <[EMAIL
Pierre Rousselet writes:
James Bourne wrote:
From the procps man page:
Albert Cahalan [EMAIL PROTECTED] rewrote ps for full
Unix98 and BSD support, along with some ugly hacks for
obsolete and foreign syntax.
Michael K. Johnson [EMAIL PROTECTED] is the
Pete Zaitcev writes:
Russel King complained that you might be calling pci_consistent_free
from an interrupt, which is unsafe on ARM.
This sure makes life difficult. Device removal events can be called
from interrupt context according to Documentation/pci.txt. This is
certainly a place where
=?iso-8859-1?Q?Jak writes:
> Hi, just wanted to recommend that this goes in, in one form or
> another - it would help a lot around here.
Yes, it looks very nice. The codes match those used by ps even.
> Today we have to manually "fix" the kernel
> source to get proper core.[executable]
=?iso-8859-1?Q?Jak writes:
Hi, just wanted to recommend that this goes in, in one form or
another - it would help a lot around here.
Yes, it looks very nice. The codes match those used by ps even.
Today we have to manually fix the kernel
source to get proper core.[executable] naming of
Alexander Viro writes:
>> On Fri, 4 May 2001, Alexander Viro wrote:
>>> Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
> ^^^
Ah, you learn from the master.
> ObProcfs: I don't think that walking the
Duncan Gauld writes:
> Information in the README file says that when patching, the -p0 option is
> used with patch (eg tar xvzf .tar.gz | patch -p0). However I have
> never got this to work as I always get something like "can't find file to
> patch at line 5". However, replacing -p0 with -p1
Duncan Gauld writes:
Information in the README file says that when patching, the -p0 option is
used with patch (eg tar xvzf patch.tar.gz | patch -p0). However I have
never got this to work as I always get something like can't find file to
patch at line 5. However, replacing -p0 with -p1
Alexander Viro writes:
On Fri, 4 May 2001, Alexander Viro wrote:
Ehh... There _is_ a way to deal with that, but it's deeply Albertesque:
^^^
Ah, you learn from the master.
ObProcfs: I don't think that walking the page
Pavel Machek writes:
> It should ot break anything. gcc decides its bad to inline it, so it
> does not inline it. Small code growth at worst. Compiler has right to
> make your code bigger or slower, if it decides to do so.
Oh come on. The logical way:
inline Compiler must inline
Tom Holroyd writes:
> On Wed, 2 May 2001, Albert D. Cahalan wrote:
>> For 32-bit systems, we use 32-bit values to reduce overhead.
>> This causes problems at 495/smp_num_cpus days of uptime.
>
> You mean for HZ == 100.
Well, OK. No unmodified 32-bit system runs HZ ==
Tom Holroyd writes:
On Wed, 2 May 2001, Albert D. Cahalan wrote:
For 32-bit systems, we use 32-bit values to reduce overhead.
This causes problems at 495/smp_num_cpus days of uptime.
You mean for HZ == 100.
Well, OK. No unmodified 32-bit system runs HZ == 1024.
And I guess the overhead
Pavel Machek writes:
It should ot break anything. gcc decides its bad to inline it, so it
does not inline it. Small code growth at worst. Compiler has right to
make your code bigger or slower, if it decides to do so.
Oh come on. The logical way:
inline Compiler must inline (only!)
> /proc/uptime:
> 4400586.27 150439.36
>
> /proc/stat:
> cpu 371049158 3972370867 8752820 4448994822
> (user,nice, system, idle)
>
> In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being
> computed by:
>
> len = sprintf(page, "cpu %u %u %u %lu\n", user,
/proc/uptime:
4400586.27 150439.36
/proc/stat:
cpu 371049158 3972370867 8752820 4448994822
(user,nice, system, idle)
In .../fs/proc/proc_misc.c:kstat_read_proc(), the cpu line is being
computed by:
len = sprintf(page, cpu %u %u %u %lu\n, user, nice, system,
Linus Torvalds writes:
> Btw, please use "static inline" instead of "extern inline", as gcc may
> decide not to inline the latter at all, leading to confusing link-time
> errors. (Gcc may also decide not to inline "static inline", but then gcc
> will output the actual body of the function
Linus Torvalds writes:
Btw, please use static inline instead of extern inline, as gcc may
decide not to inline the latter at all, leading to confusing link-time
errors. (Gcc may also decide not to inline static inline, but then gcc
will output the actual body of the function out-of-line if
What would be the cleanest driver that does everything right?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
What would be the cleanest driver that does everything right?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rogier Wolff writes:
> Wakko Warner wrote:
>>> So you've spent almost $200 for RAM, and refuse to spend
>>> $4 for 1Gb of swap space. Fine with me.
So that is a factor of 50 in price. It's what, a factor of 100
in access time?
> That disk space is just sitting there. Never to be used. I
Rogier Wolff writes:
Wakko Warner wrote:
So you've spent almost $200 for RAM, and refuse to spend
$4 for 1Gb of swap space. Fine with me.
So that is a factor of 50 in price. It's what, a factor of 100
in access time?
That disk space is just sitting there. Never to be used. I spent
Linus Torvalds writes:
> The buffer cache is "virtual" in the sense that /dev/hda is a
> completely separate name-space from /dev/hda1, even if there
> is some physical overlap.
So the aliasing problems and elevator algorithm confusion remain?
Is this ever likely to change, and what is with the
[EMAIL PROTECTED] writes:
> i wrote somewhere that it was my mistake to call it single-user when i
> mean all user has the same root cap, and reduce "user" (account) to
> "profile".
Seen this way it makes a tad more sense:
1. you and your spouse share the computer
2. you have different shells,
[EMAIL PROTECTED] writes:
i wrote somewhere that it was my mistake to call it single-user when i
mean all user has the same root cap, and reduce user (account) to
profile.
Seen this way it makes a tad more sense:
1. you and your spouse share the computer
2. you have different shells, mail
Linus Torvalds writes:
The buffer cache is virtual in the sense that /dev/hda is a
completely separate name-space from /dev/hda1, even if there
is some physical overlap.
So the aliasing problems and elevator algorithm confusion remain?
Is this ever likely to change, and what is with the 1 kB
[EMAIL PROTECTED] writes:
> i didn't change all uid/gid to 0!
>
> why? so with that radical patch, users will still have
> uid/gid so programs know the user's profile.
So you:
1. broke security (OK, fine...)
2. didn't remove all the support for security
It would be far more interesting to
Richard Gooch writes:
> We want to take out that union because it sucks for virtual
> filesystems. Besides, it's ugly.
I hope you won't mind if people trash this with benchmarks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Richard Gooch writes:
We want to take out that union because it sucks for virtual
filesystems. Besides, it's ugly.
I hope you won't mind if people trash this with benchmarks.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
Wayne writes:
> In mailing-lists.linux-kernel, Manuel A. McLure wrote:
>> Did you try nesting more than one "su -"? The first one after a boot
>> works for me - every other one fails.
>
> Same here: the first "su -" works OK, but a second nested one hangs:
>
> 8825 pts/2S 0:00 /bin/su
Wayne writes:
In mailing-lists.linux-kernel, Manuel A. McLure wrote:
Did you try nesting more than one su -? The first one after a boot
works for me - every other one fails.
Same here: the first su - works OK, but a second nested one hangs:
8825 pts/2S 0:00 /bin/su -
8826
Eric S. Raymond writes:
> This is a proposal for an attribution metadata system in the Linux
> kernel sources. The goal of the system is to make it easy for
> people reading any given piece of code to identify the responsible
> maintainer. The motivation for this proposal is that the present
>
Eric S. Raymond writes:
This is a proposal for an attribution metadata system in the Linux
kernel sources. The goal of the system is to make it easy for
people reading any given piece of code to identify the responsible
maintainer. The motivation for this proposal is that the present
Matthew Wilcox writes:
> On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
>> Doesn't this seem a little like the problems occurring with lvm right now?
>> A separate tree maintained with the maintainers not wanting others
>> submitting patches that conflict with their particular tree?
Matthew Wilcox writes:
On Thu, Apr 19, 2001 at 10:07:22PM -0600, james rich wrote:
Doesn't this seem a little like the problems occurring with lvm right now?
A separate tree maintained with the maintainers not wanting others
submitting patches that conflict with their particular tree? It
Theodore Tso writes:
> On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
>> It does not work in a relaxed "people sit at tables and comment
>> at arbitrary points in time during a talk" setting such as the
>> kernel summit. Besides putting a microphone at every table (which
>>
Nick Pollitt writes:
> Changes to array.c expose cpus_allowed in proc/pid/stat.
...
> -%lu %lu %lu %lu %lu %lu %lu %lu %d %d\n",
> +%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu\n",
...
> - task->processor);
> + task->processor,
> + task->cpus_allowed);
This
H. Peter Anvin writes:
> By author:"Heusden, Folkert van" <[EMAIL PROTECTED]>
>> Would anyone be intrested (besides me) in a kernel which can page
...
>> Certain parts of drivers could get the __pageable prefix or so
> VMS does this. It at least used to have a great tendency to crash
>
H. Peter Anvin writes:
By author:"Heusden, Folkert van" [EMAIL PROTECTED]
Would anyone be intrested (besides me) in a kernel which can page
...
Certain parts of drivers could get the __pageable prefix or so
VMS does this. It at least used to have a great tendency to crash
itself,
Nick Pollitt writes:
Changes to array.c expose cpus_allowed in proc/pid/stat.
...
-%lu %lu %lu %lu %lu %lu %lu %lu %d %d\n",
+%lu %lu %lu %lu %lu %lu %lu %lu %d %d %lu\n",
...
- task-processor);
+ task-processor,
+ task-cpus_allowed);
This isn't good.
Theodore Tso writes:
On Mon, Apr 16, 2001 at 05:53:19PM -0700, David S. Miller wrote:
It does not work in a relaxed "people sit at tables and comment
at arbitrary points in time during a talk" setting such as the
kernel summit. Besides putting a microphone at every table (which
isn't all
Miles Lane writes:
>> Randolph Bentson wrote:
>>> I've heard of conferences where a wireless audience
>>> microphone was put inside a Nerf ball. It could
>>> then be tossed to the audience member who wished
>>> to speak.
>
> Seriously though, this would probably still be an
> impediment to the
> CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
> linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
> At the same time we will NOT support the following clocks:
>
> CLOCK_VIRTUAL a clock measuring the elapsed
Guest section DW writes:
> On Mon, Apr 16, 2001 at 12:29:11AM -0600, Eric W. Biederman wrote:
>> If we can try to keycodes in 8-bits it would be nice. The difficulty
>> is that X cannot handle more than 8-bits without telling it you have
>> multiple keyboards. The keycode (at least in X) is
Andries.Brouwer writes:
>From [EMAIL PROTECTED] Mon Apr 16 08:35:09 2001
>>Andries.Brouwer writes:
>>> What one wants is to remap access to sector 0 to sector 1,
>>> and leave all other sectors alone. Thus, if someone asks
>>> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
>>
>> No,
H. Peter Anvin writes:
> This means you don't have to configure two levels (scancodes ->
> keycodes and keycodes -> keymap); since currently the keycodes are
> keyboard-specific anyway there is no benefit to the two levels.
The medium-raw level ought to be what the X11R6 protocol uses.
Then the
Andries.Brouwer writes:
> What one wants is to remap access to sector 0 to sector 1,
> and leave all other sectors alone. Thus, if someone asks
> for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
No, because then you can't write to the real first sector.
Assuming translation is good, 1 0
Andries.Brouwer writes:
What one wants is to remap access to sector 0 to sector 1,
and leave all other sectors alone. Thus, if someone asks
for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
No, because then you can't write to the real first sector.
Assuming translation is good, 1 0 2
H. Peter Anvin writes:
This means you don't have to configure two levels (scancodes -
keycodes and keycodes - keymap); since currently the keycodes are
keyboard-specific anyway there is no benefit to the two levels.
The medium-raw level ought to be what the X11R6 protocol uses.
Then the
Andries.Brouwer writes:
From [EMAIL PROTECTED] Mon Apr 16 08:35:09 2001
Andries.Brouwer writes:
What one wants is to remap access to sector 0 to sector 1,
and leave all other sectors alone. Thus, if someone asks
for sectors 0 1 2 3 4, she should get sectors 1 1 2 3 4.
No, because then you
Guest section DW writes:
On Mon, Apr 16, 2001 at 12:29:11AM -0600, Eric W. Biederman wrote:
If we can try to keycodes in 8-bits it would be nice. The difficulty
is that X cannot handle more than 8-bits without telling it you have
multiple keyboards. The keycode (at least in X) is exported
CLOCK_10MS a wall clock supporting timers with 10 ms resolution (same as
linux today).
Except on the Alpha, and on some ARM systems, etc.
The HZ constant varies from 10 to 1200.
At the same time we will NOT support the following clocks:
CLOCK_VIRTUAL a clock measuring the elapsed
Miles Lane writes:
Randolph Bentson wrote:
I've heard of conferences where a wireless audience
microphone was put inside a Nerf ball. It could
then be tossed to the audience member who wished
to speak.
Seriously though, this would probably still be an
impediment to the sort of
> * Added fast-mode command to suppress side-effect computation
> on slow machines.
You could put the computation in a low-priority thread, so that it
still gets done but doesn't mess up responsiveness.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
* Added fast-mode command to suppress side-effect computation
on slow machines.
You could put the computation in a low-priority thread, so that it
still gets done but doesn't mess up responsiveness.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
> * All three interfaces do progressive disclosure -- the user only sees
> questions he/she needs to answer (no more hundreds of greyed-out menu
> entries for irrelevant drivers!).
Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a
* All three interfaces do progressive disclosure -- the user only sees
questions he/she needs to answer (no more hundreds of greyed-out menu
entries for irrelevant drivers!).
Well, that sucks. The greyed-out menu entries were the only good
thing about xconfig. Such entries provide a clue
Martin Mares writes:
> [lost]
>> Just how would you do kernel/user CPU time accounting then ?
>> It's currently done on every timer tick, and doing it less
>> often would make it useless.
>
> Except for machines with very slow timers we really should account time
> to processes during context
Daniel Phillips writes:
> The zeroth block of an indexed directory is the index root. Initially
> the index has only one block. The following blocks are normal ext2
> directory entry blocks. When the directory grows large enough to fill
> all the available entries in the root index block
Daniel Phillips writes:
The zeroth block of an indexed directory is the index root. Initially
the index has only one block. The following blocks are normal ext2
directory entry blocks. When the directory grows large enough to fill
all the available entries in the root index block (around
Martin Mares writes:
[lost]
Just how would you do kernel/user CPU time accounting then ?
It's currently done on every timer tick, and doing it less
often would make it useless.
Except for machines with very slow timers we really should account time
to processes during context switch
> I'd prefer to inline cpu_is_idle(), but optimizing the idle
> code path is probably not that important ;-)
Sure it is, in one way: how fast can you get back to work?
(not OK to take a millisecond getting out of the idle loop)
-
To unsubscribe from this list: send the line "unsubscribe
I'd prefer to inline cpu_is_idle(), but optimizing the idle
code path is probably not that important ;-)
Sure it is, in one way: how fast can you get back to work?
(not OK to take a millisecond getting out of the idle loop)
-
To unsubscribe from this list: send the line "unsubscribe
Gregory Maxwell writes:
> On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:
>> I'm really sick of being buried in useless information. The signal
>> gets lost in the noise. It is easy to discard automatically generated
>> bug reports, and way too ann
Manfred Spraul writes:
> [Larry McVoy]
>> There was a lot of discussion about possible tools
>> that would dig out the /proc/pci info
>
> I think the tools should not dig too much information out of the system.
> I remember some Microsoft (win98 beta?) bugtracking software that
> insisted on
> Problem details
> Bug report quality
> There was lots of discussion on this. The main agreement was that we
> wanted the bug reporting system to dig out as much info as possible
> and prefill that. There was a lot of discussion about possible tools
> that would dig
Problem details
Bug report quality
There was lots of discussion on this. The main agreement was that we
wanted the bug reporting system to dig out as much info as possible
and prefill that. There was a lot of discussion about possible tools
that would dig out
Manfred Spraul writes:
[Larry McVoy]
There was a lot of discussion about possible tools
that would dig out the /proc/pci info
I think the tools should not dig too much information out of the system.
I remember some Microsoft (win98 beta?) bugtracking software that
insisted on sending a
Gregory Maxwell writes:
On Sun, Apr 01, 2001 at 03:43:52PM -0400, Albert D. Cahalan wrote:
I'm really sick of being buried in useless information. The signal
gets lost in the noise. It is easy to discard automatically generated
bug reports, and way too annoying to wade through the crud
Ingo Molnar writes:
> the attached pae-2.4.3-C3 patch fixes the PAE code to work with SLAB
> FORCED_DEBUG (which enables redzoning) too.
>
> the problem is that redzoning is enabled unconditionally, and SLAB has no
> information about how crutial alignment is in the case of any particular
>
Ingo Molnar writes:
the attached pae-2.4.3-C3 patch fixes the PAE code to work with SLAB
FORCED_DEBUG (which enables redzoning) too.
the problem is that redzoning is enabled unconditionally, and SLAB has no
information about how crutial alignment is in the case of any particular
SLAB
Andrew Pimlott writes:
> On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
>> The problems with devfs (other than kernel memory bloat, which is pretty
>> much guaranteed to be much worse than the bloat a larger dev_t would
>> entail) is that it needs complex auxilliary mechanisms
[EMAIL PROTECTED] writes:
> [Linus Torvalds]
>> You'e now forced every piece of code that needs a dev_t
>> to carry along the overhead of having a 64-bit field
>
> Let me repeat: there is no such code. In user space dev_t already is
> 64 bits, whether you like it or not. We cannot go back to
[EMAIL PROTECTED] writes:
[Linus Torvalds]
You'e now forced every piece of code that needs a dev_t
to carry along the overhead of having a 64-bit field
Let me repeat: there is no such code. In user space dev_t already is
64 bits, whether you like it or not. We cannot go back to libc5.
...
Andrew Pimlott writes:
On Tue, Mar 27, 2001 at 02:13:47PM -0800, H. Peter Anvin wrote:
The problems with devfs (other than kernel memory bloat, which is pretty
much guaranteed to be much worse than the bloat a larger dev_t would
entail) is that it needs complex auxilliary mechanisms to make
Riley Williams writes:
> Hi Albert.
The rule should be like this:
List the lowest version number required to get
2.2.xx-level features while running a 2.4.xx kernel.
>>> Replace that "a 2.2.xx" with "my current" and remove all
>>> restrictions on what the current
Riley Williams writes:
Hi Albert.
The rule should be like this:
List the lowest version number required to get
2.2.xx-level features while running a 2.4.xx kernel.
Replace that "a 2.2.xx" with "my current" and remove all
restrictions on what the current kernel is, and that becomes
Riley Williams writes:
>> The rule should be like this:
>>
>> List the lowest version number required to get
>> 2.2.xx-level features while running a 2.4.xx kernel.
>
> That's a meaningless definition, and can only be taken as such. What
> use would such a list be to somebody wishing
Andries.Brouwer writes:
>> From: "Albert D. Cahalan" <[EMAIL PROTECTED]>
>>> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
>>>>> +o Console Tools # 0.3.3# loadkeys -V
>>>>> +o Mount # 2.10e
Andries.Brouwer writes:
From: "Albert D. Cahalan" [EMAIL PROTECTED]
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
+o Console Tools # 0.3.3# loadkeys -V
+o Mount # 2.10e# mount --version
Concerning mount: (i) the version mentioned is too old,
Alexander Viro writes:
> On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
>>> +o Console Tools # 0.3.3# loadkeys -V
>>> +o Mount # 2.10e# mount --version
>>
>> Concerning mount: (i) the version mentioned is too old,
Exactly why? Mere missing features don't
Alexander Viro writes:
On Wed, 14 Mar 2001 [EMAIL PROTECTED] wrote:
+o Console Tools # 0.3.3# loadkeys -V
+o Mount # 2.10e# mount --version
Concerning mount: (i) the version mentioned is too old,
Exactly why? Mere missing features don't make for a
Nathan Paul Simons writes:
> On Tue, Mar 13, 2001 at 04:05:13PM -0500, Albert D. Cahalan wrote:
>> Bloat removal: being able to run without /proc mounted.
>>
>> We don't have "kernel speed". We have kernel-mode screwing around
>> with text formatting.
>
&
Nathan Paul Simons writes:
> On Mon, Mar 12, 2001 at 09:21:37PM +, Guennadi Liakhovetski wrote:
>> CPU utilisation. Each new application has to calculate it (ps, top, qps,
>> kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
>> syscall for that? Wouldn't it be more
Nathan Paul Simons writes:
On Mon, Mar 12, 2001 at 09:21:37PM +, Guennadi Liakhovetski wrote:
CPU utilisation. Each new application has to calculate it (ps, top, qps,
kps, various sysmons, procmons, etc.). Wouldn't it be worth it having a
syscall for that? Wouldn't it be more optimal?
Nathan Paul Simons writes:
On Tue, Mar 13, 2001 at 04:05:13PM -0500, Albert D. Cahalan wrote:
Bloat removal: being able to run without /proc mounted.
We don't have "kernel speed". We have kernel-mode screwing around
with text formatting.
Or calculating things that rea
Geert Uytterhoeven writes:
> - The colors for the 16 color logo are wrong. We used a hack to
> give the logo its own color palette, but this no longer works
> as a side effect of a console color map bug being fixed a while
> ago. The solution is to replace the logo with a new one
Jochen Dolze writes:
> i found at http://acl.bestbits.at the ACL-linux-project. Now i want to know,
> if there is a plan to integrate posix-ACLs into the fs-part of the kernel,
> e.g. into the VFS-Layer? Is there a general discussion about this anywhere?
> What are the biggest problems? (i know
Geert Uytterhoeven writes:
- The colors for the 16 color logo are wrong. We used a hack to
give the logo its own color palette, but this no longer works
as a side effect of a console color map bug being fixed a while
ago. The solution is to replace the logo with a new one that
Hank Leininger writes:
> On 2001-03-07, "Albert D. Cahalan" <[EMAIL PROTECTED]> wrote:
>> Then for proper ps and top output, you need a reasonably efficient
>> way to grab all threads as a group. This could be as simple as
>> ensuring that /proc director
Hank Leininger writes:
On 2001-03-07, "Albert D. Cahalan" [EMAIL PROTECTED] wrote:
Then for proper ps and top output, you need a reasonably efficient
way to grab all threads as a group. This could be as simple as
ensuring that /proc directory reads return related tasks together.
Helge Hafting writes:
> Gregory Maxwell wrote:
>> There are no threads in Linux.
>> All tasks are processes.
>> Processes can share any or none of a vast set of resources.
>
> Is there a way a user program can find out what resources
> are shared among which processes?
>
> That would allow
Kevin Buhr writes:
> "Albert D. Cahalan" <[EMAIL PROTECTED]> writes:
>> So you change it to 2... but what about the "float" type? It gets
>> a mixture of 64-bit and 32-bit IEEE arithmetic depending rather
>> unpredictably on compiler register
David G\363mez writes:
> Hi, i've got a newbie question about patches:
> Are the pre* patches ( and i guess also the ac* ones) applied against the
> last release of the kernel or against the previous patch? I mean, when
> 2.4.3pre2 will come out, i need to get also the pre1 patch?
Really, I
Kevin Buhr writes:
> It boils down to the fact that, under i386 Linux, the FPU control word
> has its precision control (PC) set to 3 (for 80-bit extended
> precision) while under i386 FreeBSD, NetBSD, and others, it's set to 2
> (for 64-bit double precision). On other architectures, I assume
>
Kevin Buhr writes:
It boils down to the fact that, under i386 Linux, the FPU control word
has its precision control (PC) set to 3 (for 80-bit extended
precision) while under i386 FreeBSD, NetBSD, and others, it's set to 2
(for 64-bit double precision). On other architectures, I assume
David G\363mez writes:
Hi, i've got a newbie question about patches:
Are the pre* patches ( and i guess also the ac* ones) applied against the
last release of the kernel or against the previous patch? I mean, when
2.4.3pre2 will come out, i need to get also the pre1 patch?
Really, I
Kevin Buhr writes:
"Albert D. Cahalan" [EMAIL PROTECTED] writes:
So you change it to 2... but what about the "float" type? It gets
a mixture of 64-bit and 32-bit IEEE arithmetic depending rather
unpredictably on compiler register allocations and optimizations???
Wel
Christoph Hellwig writes:
> On Wed, Feb 28, 2001 at 10:16:02PM -0500, Albert D. Cahalan wrote:
>> Christoph Hellwig writes:
>>
>>> Urgg. limits.h is a userlevel header...
>>>
>>> The attached patch will make similar atempts fail (but not this one as
>
101 - 200 of 439 matches
Mail list logo
