l device interrupt overhead
>> lower), but I'd be very wary of using it in production.
>
> Darn it. I was actually hoping that someone else could have the
> reputation of doing "I can't believe they actually did this" code in the
> kernel.
Hey, I tried: http://article.gm
/1594134
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
e whatsoever, right?).
The point is that /dev/kmsg is *not* intended as a syslog replacement.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
ilful bad behavior
> unless that is shown to be necessary. Yeah, if it turns out that
> systemd really does that just to mess with us, we'd need to extend it,
> but in the absence of proof to the contrary, maybe this simple
> attached patch works?
Once is an accident. Twice is incompetence. Thre
is malice.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
res the stack to be made executable in order for the
> program to work properly.
>
> That might work.
That sounds like it will only warn if a trampoline is needed. A nested
function whose address isn't taken, as is the case here, wouldn't
trigger this warning.
--
Måns Rullgård
m...
.
That might work.
That sounds like it will only warn if a trampoline is needed. A nested
function whose address isn't taken, as is the case here, wouldn't
trigger this warning.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
if( adapno >= hba_count )
> return (-ENODEV);
This relies on implementation-defined behaviour when converting an
unsigned integer to signed integer. A simpler and more robust fix is to
make the local variable 'adapno' unsigned.
--
Måns Rullgård
)
return (-ENODEV);
This relies on implementation-defined behaviour when converting an
unsigned integer to signed integer. A simpler and more robust fix is to
make the local variable 'adapno' unsigned.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe
Nicolas Pitre writes:
> On Tue, 12 Nov 2013, Måns Rullgård wrote:
>
>> Nicolas Pitre writes:
>>
>> > On Tue, 12 Nov 2013, Ben Dooks wrote:
>> >
>> >> Given these are single instructoins for ARM, is it possible we could
>> >> make a
ions) but I doubt that people would accept that.
It might be possible to extract this information from relocation tables.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
details]
>
> 1374pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx],
> (u32 *));
> 1375pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx]
> + 4, (u32 *) + 1);
> 1376
> 1377 return count;
> 1378}
This looks intentional and correct apart
iler might do evil things with what to it looks like
out of bounds indexing.
There should also be some cache maintenance after this patching, or is
that already happening for some other reason?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe l
have to jump to this function. It would be great
> if we could inline this function at the call site but as I already said
> I don't know how to do that.
Ideally the bl instruction at the call site would be patched over with
sdiv/udiv when supported. This would leave things exactly a
when supported. This would leave things exactly as they are
for hardware without div capability and incur only the call setup cost
(but no actual call) on div-capable hardware. No, I don't know how to
achieve this.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line
indexing.
There should also be some cache maintenance after this patching, or is
that already happening for some other reason?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
);
1375pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc-idx]
+ 4, (u32 *)count + 1);
1376
1377return count;
1378}
This looks intentional and correct apart from possible strict aliasing
issues.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line
would accept that.
It might be possible to extract this information from relocation tables.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
Nicolas Pitre nicolas.pi...@linaro.org writes:
On Tue, 12 Nov 2013, Måns Rullgård wrote:
Nicolas Pitre nicolas.pi...@linaro.org writes:
On Tue, 12 Nov 2013, Ben Dooks wrote:
Given these are single instructoins for ARM, is it possible we could
make a table of all the callers and fix
(and move the
values to/from r0/r1) that would not be needed if the div instructions
were done inline (obviously such a kernel could only run on hardware
with division support).
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
registers (and move the
values to/from r0/r1) that would not be needed if the div instructions
were done inline (obviously such a kernel could only run on hardware
with division support).
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
return ret;
> + }
> +
> + return ___aeabi_idiv(numerator, denominator);
> +}
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
);
+}
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Rob Landley writes:
> On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
>> Rob Landley writes:
>>
>> > On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
>> >> I'd strongly suggest you make your binutils compatible with newer
>> >> instruction
Rob Landley r...@landley.net writes:
On 09/25/2013 10:52:44 AM, Måns Rullgård wrote:
Rob Landley r...@landley.net writes:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel
break your precious assembler.
>
> I've got news for you. We're *not* going to listen to that argument.
>
> END OF DISCUSSION (everything else is just a waste of time.)
I fully agree.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
nd on
> endless new gnuisms just because they're there and nobody else is
> regression testing against them, not because they actually add anything.
Since when is assembling the instructions correctly, as specified in the
arch ref, and not in some other random way a gnuism?
--
M
new gnuisms just because they're there and nobody else is
regression testing against them, not because they actually add anything.
Since when is assembling the instructions correctly, as specified in the
arch ref, and not in some other random way a gnuism?
--
Måns Rullgård
m...@mansr.com
. We're *not* going to listen to that argument.
END OF DISCUSSION (everything else is just a waste of time.)
I fully agree.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
inutils older than 2.19
or so rarely works properly for ARM.
What value is there in maintaining compatibility with a truly ancient
binutils version anyway?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
rarely works properly for ARM.
What value is there in maintaining compatibility with a truly ancient
binutils version anyway?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
ot;Q" (sp));
This doesn't do quite the same thing. The existing code pretends to
read something from the stack in order to create a barrier of some
sort. Your new code stores the value of the stack pointer to a location
on the stack for consumption by the "Q" memory constr
beh...@converseincode.com writes:
> +#define current_stack_pointer ({ \
> + unsigned long current_sp; \
> + asm ("mov %0, r13" : "=r" (current_sp)); \
> + current_sp; \
> +})
Why do you use 'r13' rather than the more common 'sp' alias
beh...@converseincode.com writes:
+#define current_stack_pointer ({ \
+ unsigned long current_sp; \
+ asm (mov %0, r13 : =r (current_sp)); \
+ current_sp; \
+})
Why do you use 'r13' rather than the more common 'sp' alias?
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from
to create a barrier of some
sort. Your new code stores the value of the stack pointer to a location
on the stack for consumption by the Q memory constraint. This store
is not necessary and should preferably be avoided.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line
.
LDA uses the address generation circuitry from the load/store unit, but
it does not actually access memory. It is merely a convenient way of
performing certain arithmetic operations, be it for scheduling reasons
or for the different range of immediate values available.
--
Måns Rullgård
m...@mansr.com
or for the different range of immediate values available.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
]
>
> We already changed that once from %td to %zd so that the size_t works
> correctly.
If the argument is correctly of type size_t, the format should be '%zu'
since size_t is unsigned.
> Does a signed size_t make any sense?
A signed type corresponding to size_t sometimes makes sens
that once from %td to %zd so that the size_t works
correctly.
If the argument is correctly of type size_t, the format should be '%zu'
since size_t is unsigned.
Does a signed size_t make any sense?
A signed type corresponding to size_t sometimes makes sense and it's
called ssize_t.
--
Måns
nd the "beauty" of this name (I
> have my own opinion) but we spend too much time arguing about it. This
> name has implications beyond the technical arguments of some script or
> another and it will be found in all the technical documents produced by
> ARM Ltd (including the nex
the aarch64 name was
chosen. Assuming it wasn't handed down by a supreme being, there has
to be some reasoning behind the choice.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
ual bit encoding):
>>
>> http://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html
>
> "This document is only available in a PDF version to registered ARM
> customers."
>
> It would be nice to make this public :-(.
Anyone can register, so it's not all that bad.
://infocenter.arm.com/help/topic/com.arm.doc.genc010197a/index.html
This document is only available in a PDF version to registered ARM
customers.
It would be nice to make this public :-(.
Anyone can register, so it's not all that bad.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send
sons:
- Those are the names people actually use to refer to the architecture
- They are more descriptive.
- I think the official name is rather silly.
Note, these are my personal opinions.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
--
Måns Rullgård
m...@mansr.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
communication protocol. No tainting is
> involved, as all corruption in your kernel is caused by kernel bugs in
> visible code that can be debugged.
Untrusted code doesn't necessarily violate the GPL. The two issues
are orthogonal.
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe
rs claim that at trade shows, you should not hand over
> a demo device running GPLed code to any interested party, as it would be
> distribution...
Lawyers tend to be overly cautious at times. That said, I am not a
lawyer, and may have misunderstood something. If that is the case, I
apologise for any
at times. That said, I am not a
lawyer, and may have misunderstood something. If that is the case, I
apologise for any confusion I may have caused.
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
doesn't necessarily violate the GPL. The two issues
are orthogonal.
--
Måns Rullgård
[EMAIL PROTECTED]
--
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
Adrian Bunk <[EMAIL PROTECTED]> writes:
> On Tue, Jan 29, 2008 at 11:25:22PM +0000, Måns Rullgård wrote:
>> Adrian Bunk <[EMAIL PROTECTED]> writes:
>>
>> > On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
>> >> Hello!
>> >&g
in the matter. The Windows drivers are (unrelated
violations aside) clearly not derived from GPL code.
IANAL
--
Måns Rullgård
[EMAIL PROTECTED]
--
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/
linking of not GPLv2 compatible code into GPLv2 code was
not a copyright violation.
As long as you don't distribute /proc/kcore, I can't see how the GPL
would have any say in the matter. The Windows drivers are (unrelated
violations aside) clearly not derived from GPL code.
IANAL
--
Måns
Adrian Bunk [EMAIL PROTECTED] writes:
On Tue, Jan 29, 2008 at 11:25:22PM +, Måns Rullgård wrote:
Adrian Bunk [EMAIL PROTECTED] writes:
On Tue, Jan 29, 2008 at 04:22:45PM -0500, Pavel Roskin wrote:
Hello!
It have come to my attention that a patch has been committed to the
kernel
persist.
>
> This is a know problem?
Probably something to do with this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecb77fa96ceda9cae88015bfe3293ffe19006159
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line "
?
Probably something to do with this commit:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ecb77fa96ceda9cae88015bfe3293ffe19006159
--
Måns Rullgård
[EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
M. On ARM1136 (used in the Nokia N800) a mispredicted branch takes
5-7 cycles (a correctly predicted branch takes 0-4 cycles), while a
conditional load, store or arithmetic instruction always takes one
cycle.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line &
or arithmetic instruction always takes one
cycle.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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
mitted the patch.
> You, implicitly, by acking a patch saying those parens are bad.
> But not me ... I don't think this patch is merge-worthy.
Would also add rules like "don't put parens around the word device"
etc? There are countless silly things one could do, and we can'
are bad.
But not me ... I don't think this patch is merge-worthy.
Would also add rules like don't put parens around the word device
etc? There are countless silly things one could do, and we can't
explicitly prohibit all of them.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list
Chris Boot <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> Chris Boot <[EMAIL PROTECTED]> writes:
>>
>>
>>> All,
>>>
>>> I've got a box running RHEL5 and haven't been impressed by ext3
>>> performance on it (running of a 1
/0x23
> [] vfs_readdir+0x63/0x8d
> [] filldir+0x0/0xb9
> [] sys_getdents+0x5f/0x9c
> [] syscall_call+0x7/0xb
> ===
Your Redhat kernel is probably built with 4k stacks and XFS+loop+ext3
seems to be enough to overflow it.
--
Måns Rullgård
[EMAIL PROTECTED]
-
T
[c047a447] sys_getdents+0x5f/0x9c
[c0403eff] syscall_call+0x7/0xb
===
Your Redhat kernel is probably built with 4k stacks and XFS+loop+ext3
seems to be enough to overflow it.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux
Chris Boot [EMAIL PROTECTED] writes:
Måns Rullgård wrote:
Chris Boot [EMAIL PROTECTED] writes:
All,
I've got a box running RHEL5 and haven't been impressed by ext3
performance on it (running of a 1.5TB HP MSA20 using the cciss
driver). I compiled XFS as a module and tried it out since
llocated.
I don't have dedicated testing machines, so I can't afford the time
and potential data loss of testing this regularly. I have no shortage
on RAM with 8k stacks, so for me the choice is quite simple.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscr
this regularly. I have no shortage
on RAM with 8k stacks, so for me the choice is quite simple.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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
like Fedora and RHEL use 4K stacks
> since forever, and if it gave massive problems they wouldn't do that.
> On the upside, especially on very-threaded workloads, it helps
> reliability and the VM a lot...
I guess no Fedora users run md+lvm+xfs then. That combination has
quite reliably cr
then. That combination has
quite reliably crashed any 4k-stack kernel I've ever cared to try.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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
d
>> counter-productive in any case.
>
> Well, then please write this to the person who did attack me for no
> reason!
>
> What he did is typical trollish behavior, as he tried to turn a
> technical based discussion into a flame war for no reason.
Ah, it's nice to see Jörg back to
fantastic real-life flame war you
gave us at LinuxTag (by the Google booth, remember). I haven't had so
much fun in a long time. Quite a few bystanders seemed rather
entertained too.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel
out what KDE
(or Gnome) is supposed to be good for. I'm not missing anything from
my window manager, xterm and xemacs setup.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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/
developers generally put *much* effort into making APIs
as logical and friendly as they possibly can.
I've still not, after all these years, managed to figure out what KDE
(or Gnome) is supposed to be good for. I'm not missing anything from
my window manager, xterm and xemacs setup.
--
Måns
mething works better for me than any kernel before it.
It's certainly not only getting worse.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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/
.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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/
proper
> mechanism to enumerate all tasks is to use a do_each_thread() +
> while_each_thread() loop.
Was this always a bug or did the meaning of for_each_process() change
since this code was added?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubsc
a do_each_thread() +
while_each_thread() loop.
Was this always a bug or did the meaning of for_each_process() change
since this code was added?
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Friday 20 April 2007 10:35:10 Måns Rullgård wrote:
>> Arjan van de Ven <[EMAIL PROTECTED]> writes:
>>
>> > Andi Kleen wrote:
>> >> Rationale:
>> >> - It cannot be enabled in normal builds b
SuSE; I've not heard it on any
> other distro...
Even with that option set, the full kernel build with my configuration
finishes in one minute flat on my Gentoo box. Could it be that the
linker uses enormous amounts of memory? I have 4GB so I wouldn't
immediately notice.
--
Måns Rullgår
with that option set, the full kernel build with my configuration
finishes in one minute flat on my Gentoo box. Could it be that the
linker uses enormous amounts of memory? I have 4GB so I wouldn't
immediately notice.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
Andi Kleen [EMAIL PROTECTED] writes:
On Friday 20 April 2007 10:35:10 Måns Rullgård wrote:
Arjan van de Ven [EMAIL PROTECTED] writes:
Andi Kleen wrote:
Rationale:
- It cannot be enabled in normal builds because all current lds
become very slow when they have to handle thousands
Rao Davide <[EMAIL PROTECTED]> writes:
> Is LVM working on the alpha port 2.6 kernel series ?
Works for me.
> If so where do I get libdevmapper so that I can build the userspace
> LVM utils ?
Same place as you'd get it for any other system. Doesn't your
distribution includ
Rao Davide [EMAIL PROTECTED] writes:
Is LVM working on the alpha port 2.6 kernel series ?
Works for me.
If so where do I get libdevmapper so that I can build the userspace
LVM utils ?
Same place as you'd get it for any other system. Doesn't your
distribution include it?
--
Måns Rullgård
hich would be the best option, or by reading a label
> on a drive)?
Seagate drives have the firmware version printed on the label. The
version is also visible in "dmesg" output:
Vendor: ATA Model: ST3160827AS Rev: 3.03
Type: Direct-Access
on the label. The
version is also visible in dmesg output:
Vendor: ATA Model: ST3160827AS Rev: 3.03
Type: Direct-Access ANSI SCSI revision: 05
The Rev number is the firmware version.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
e fault-resistent). This way, the image
> loaded by the bootloader could be held on display up to the graphical
> login, and even as the
> desktop background, without any visible effect.
>
> Is this technically feasible?
It's technically pointless. Take a look at bootsplash, thou
could be held on display up to the graphical
login, and even as the
desktop background, without any visible effect.
Is this technically feasible?
It's technically pointless. Take a look at bootsplash, though.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line
ding "software" and "free".
> This whole thread and gotten truly bizarre.
Surprised?
--
Måns Rullgård
[EMAIL PROTECTED]
-
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
thread and gotten truly bizarre.
Surprised?
--
Måns Rullgård
[EMAIL PROTECTED]
-
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
accessible only for root, and if hacker has root permissions,
> existence of nice attribute is meaningless.
You forgot something: this idea of yours needs to be implemented,
tested, and debugged. Those things take time, and effort, and are
still of very little value.
--
Måns Rullgård
[EMAIL PROTECTE
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> So you are proposing the addition of a per-file attribute, with
>> restricted access, and potentially dangerous effects if set
>> incorrectly. This, combined with the fact that is unlikely to receive
>>
"Richard B. Johnson" <[EMAIL PROTECTED]> writes:
> On Fri, 1 Apr 2005, [iso-8859-1] Måns Rullgård wrote:
>
>> linux-os <[EMAIL PROTECTED]> writes:
>>
>>> [PATCH snipped]
>>>
>>> Cruel joke. Now 80 percent of the Intel cl
ithout i386 support, you don't have any embedded systems. You
> need to use the garbage Motorola CPUs and the proprietary
> operating systems in embedded stuff.
In front me at the moment are two embedded devices, one PPC based, the
other MIPS, both running Linux.
--
Måns Rullgård
[EMAIL PRO
any embedded systems. You
need to use the garbage Motorola CPUs and the proprietary
operating systems in embedded stuff.
In front me at the moment are two embedded devices, one PPC based, the
other MIPS, both running Linux.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list
Richard B. Johnson [EMAIL PROTECTED] writes:
On Fri, 1 Apr 2005, [iso-8859-1] Måns Rullgård wrote:
linux-os [EMAIL PROTECTED] writes:
[PATCH snipped]
Cruel joke. Now 80 percent of the Intel clones won't boot.
Those are the ones that run industry, you know, the stuff that
is necessary
Wiktor [EMAIL PROTECTED] writes:
Måns Rullgård wrote:
So you are proposing the addition of a per-file attribute, with
restricted access, and potentially dangerous effects if set
incorrectly. This, combined with the fact that is unlikely to receive
much testing, all speaks against
is meaningless.
You forgot something: this idea of yours needs to be implemented,
tested, and debugged. Those things take time, and effort, and are
still of very little value.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
;> a simple wrapper, only for the shell.
>
> Even better: Write a C wrapper for each affected program that just renices
> it as needed.
The OP was too lazy to do this.
--
Måns Rullgård
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
to do this.
--
Måns Rullgård
[EMAIL PROTECTED]
-
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/
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>>
>> You could wrap /lib/ld-linux.so, and get all dynamically linked
>> programs done in one sweep.
>>
> That's mad idea -
Sure, but it's possible.
> keep similar things in one place! starting prog
Wiktor <[EMAIL PROTECTED]> writes:
> Måns Rullgård wrote:
>> It can be done entirely in userspace, if you want it. Just hack your
>> shell to examine some extended attribute of your choice, and adjust
>> the nice value before executing files. Then arran
701 - 800 of 818 matches
Mail list logo
