Anton Altaparmakov <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
> > On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
> > > > I completely disagree with you given that this is not "inventing
> > > > [...] own memory allocators", it is just a convenient short
Anton Altaparmakov [EMAIL PROTECTED] wrote:
On Fri, 2005-09-09 at 15:02 +0300, Pekka J Enberg wrote:
On Fri, 9 Sep 2005, Anton Altaparmakov wrote:
I completely disagree with you given that this is not inventing
[...] own memory allocators, it is just a convenient short hand.
I am
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
[...]
> > But the real crux of the argument here is not whether or not people should
> > ever use binary-only drivers, it's whether the open source kernel
> > developers should spend any time
Willy Tarreau [EMAIL PROTECTED] wrote:
On Mon, Sep 05, 2005 at 12:47:03AM -0400, Sean wrote:
[...]
But the real crux of the argument here is not whether or not people should
ever use binary-only drivers, it's whether the open source kernel
developers should spend any time worrying about
Bas Westerbaan <[EMAIL PROTECTED]> wrote:
> > Yes you are. You're asking for 4KSTACKS config option to maintained
> > and it is not something you get for free. Besides, if it is indeed
> > ripped out of mainline kernel, you can always keep it a separate patch
> > for ndiswrapper.
> Though 4K
Andreas Hartmann <[EMAIL PROTECTED]> wrote:
1> Alex Riesen wrote:
> > On 9/3/05, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> >> Hello!
> >> Is it possible to prevent a program to be straced on x86?
> >> What do I have to do, eg., to prevent a perl-program to be straced?
Look at the contortions
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 9/4/05, Harald Welte <[EMAIL PROTECTED]> wrote:
> > On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
> > > Hi!
> > >
> > > Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
> > > Smartcard Reader.
> >
> > Sorry, the patch was
Andreas Hartmann [EMAIL PROTECTED] wrote:
1 Alex Riesen wrote:
On 9/3/05, Andreas Hartmann [EMAIL PROTECTED] wrote:
Hello!
Is it possible to prevent a program to be straced on x86?
What do I have to do, eg., to prevent a perl-program to be straced?
Look at the contortions shc does for
Jesper Juhl [EMAIL PROTECTED] wrote:
On 9/4/05, Harald Welte [EMAIL PROTECTED] wrote:
On Sun, Sep 04, 2005 at 12:12:18PM +0200, Harald Welte wrote:
Hi!
Below you can find a driver for the Omnikey CardMan 4040 PCMCIA
Smartcard Reader.
Sorry, the patch was missing a cg-add of the
Bas Westerbaan [EMAIL PROTECTED] wrote:
Yes you are. You're asking for 4KSTACKS config option to maintained
and it is not something you get for free. Besides, if it is indeed
ripped out of mainline kernel, you can always keep it a separate patch
for ndiswrapper.
Though 4K stacks are used
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
> >
> > Do this instead:
> > char ln[LINE_SIZE], *line;
> >
> Right, now why didn't I think of that :)
>
> Jeff: Does the patch below agree with you more?
>
>
> Signed-off-by: Jesper Juhl
[EMAIL PROTECTED] wrote:
>>On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
>>I don't know, because tar is probably more widely used and
>>consequently people are more familiar with how to use it.
>>>As I said before, the cpio format is cleaner/easier to parse in
[EMAIL PROTECTED] wrote:
On Thu, Aug 25, 2005 at 12:35:22AM -0400, [EMAIL PROTECTED] wrote:
I don't know, because tar is probably more widely used and
consequently people are more familiar with how to use it.
As I said before, the cpio format is cleaner/easier to parse in the
Jesper Juhl [EMAIL PROTECTED] wrote:
On Wednesday 24 August 2005 22:39, Brian Gerst wrote:
Do this instead:
char ln[LINE_SIZE], *line;
Right, now why didn't I think of that :)
Jeff: Does the patch below agree with you more?
Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
---
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> Convert strtok() use to strsep() in usr/gen_init_cpio.c
This is userland code...
No, I'm not looking it over carfully, just a fast look over.
> I've compile tested this patch and it compiles fine.
You should be able ti test it then.
> I build a
Jesper Juhl [EMAIL PROTECTED] wrote:
Convert strtok() use to strsep() in usr/gen_init_cpio.c
This is userland code...
No, I'm not looking it over carfully, just a fast look over.
I've compile tested this patch and it compiles fine.
You should be able ti test it then.
I build a
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Fri, 2005-08-19 at 00:10 -0700, Andrew Morton wrote:
> > Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > I believe we just ignored sparc64. That usually works for solving these
> > > kind of bugs. 8)
> >
> > heh. iirc, it was demonstrable on x86
Rusty Russell [EMAIL PROTECTED] wrote:
On Fri, 2005-08-19 at 00:10 -0700, Andrew Morton wrote:
Rusty Russell [EMAIL PROTECTED] wrote:
I believe we just ignored sparc64. That usually works for solving these
kind of bugs. 8)
heh. iirc, it was demonstrable on x86 also.
No.
Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 17, 2005 at 11:54:23AM +0200, Christian Ehrhardt wrote:
> > Your Patch at (URL wrapped)
> >
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; \
> > a=commit;h=99c6e60afff8a7bc6121aeb847dab27c556cf0c9
> >
Andi Kleen [EMAIL PROTECTED] wrote:
On Wed, Aug 17, 2005 at 11:54:23AM +0200, Christian Ehrhardt wrote:
Your Patch at (URL wrapped)
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/old-2.6-bkcvs.git; \
a=commit;h=99c6e60afff8a7bc6121aeb847dab27c556cf0c9
introduced
DervishD <[EMAIL PROTECTED]> wrote:
> * Pete Zaitcev <[EMAIL PROTECTED]> dixit:
> > On Wed, 10 Aug 2005 21:22:43 +0200, DervishD <[EMAIL PROTECTED]> wrote:
> > > I'm not using hotplug currently so... how can I make the USB
> > > subsystem to assign always the same /dev/sd? entry to my USB
DervishD [EMAIL PROTECTED] wrote:
* Pete Zaitcev [EMAIL PROTECTED] dixit:
On Wed, 10 Aug 2005 21:22:43 +0200, DervishD [EMAIL PROTECTED] wrote:
I'm not using hotplug currently so... how can I make the USB
subsystem to assign always the same /dev/sd? entry to my USB Mass
storage
Xin Zhao <[EMAIL PROTECTED]> wrote:
> I want to lock down a directory to be read-only, say, /etc, for system
> security.
If root can bypass that somehow, it is useless anyway.
> Unfortunately, some valid system tools might need to
> create/modified files like "/etc/dhclient-eth0.conf".
Xin Zhao [EMAIL PROTECTED] wrote:
I want to lock down a directory to be read-only, say, /etc, for system
security.
If root can bypass that somehow, it is useless anyway.
Unfortunately, some valid system tools might need to
create/modified files like /etc/dhclient-eth0.conf. To
Horst von Brand <[EMAIL PROTECTED]> wrote:
> In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
> ipi_handler(), a function that is only declared under CONFIG_SMP (from line
> 139 onwards). As a result, the build fails.
Sorry for the noise, a few minutes later the upda
In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
ipi_handler(), a function that is only declared under CONFIG_SMP (from line
139 onwards). As a result, the build fails.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica
In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
ipi_handler(), a function that is only declared under CONFIG_SMP (from line
139 onwards). As a result, the build fails.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica
Horst von Brand [EMAIL PROTECTED] wrote:
In arch/i386/kernel/cpu/mtrr/main.c at line 225 it references
ipi_handler(), a function that is only declared under CONFIG_SMP (from line
139 onwards). As a result, the build fails.
Sorry for the noise, a few minutes later the updated git version works
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> "extern inline" doesn't make much sense.
The gcc info here (4.0.1-4 on Fedora rawhide) says it means that the
function should be inlined, and no local copy should be generated
ever. This way the build will bomb out when something isn't inlined.
It also
[EMAIL PROTECTED] wrote:
> I am currently using Slackware 10.1 with 2.4.29 kernel and encountered
> following problem:
> I use Sagem Fast 800 ADSL modem of my provider and use my linux station
> as a router (iptables+masquerade). The problem is that after a few hours
> of working my linux
[EMAIL PROTECTED] wrote:
I am currently using Slackware 10.1 with 2.4.29 kernel and encountered
following problem:
I use Sagem Fast 800 ADSL modem of my provider and use my linux station
as a router (iptables+masquerade). The problem is that after a few hours
of working my linux crashes
Adrian Bunk [EMAIL PROTECTED] wrote:
extern inline doesn't make much sense.
The gcc info here (4.0.1-4 on Fedora rawhide) says it means that the
function should be inlined, and no local copy should be generated
ever. This way the build will bomb out when something isn't inlined.
It also says
Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Jiri Slaby napsal(a):
> > Are these files obsolete and could be deleted from tree.
> > Does anybody use them? Could anybody compile them?
>
> New list should be:
[...]
> sound/oss/skeleton.c
I think skeleton.* files are there as examples, not for real
Jiri Slaby [EMAIL PROTECTED] wrote:
Jiri Slaby napsal(a):
Are these files obsolete and could be deleted from tree.
Does anybody use them? Could anybody compile them?
New list should be:
[...]
sound/oss/skeleton.c
I think skeleton.* files are there as examples, not for real use. Sure,
Jesper Juhl <[EMAIL PROTECTED]> wrote:
> On 7/11/05, Michael S. Tsirkin <[EMAIL PROTECTED]> wrote:
> [snip]
> > 3e. sizeof
> > space after the operator
> > sizeof a
> I don't think that's a hard rule, there's plenty of code that does
> "sizeof(type)" and not "sizeof (type)",
Jesper Juhl [EMAIL PROTECTED] wrote:
On 7/11/05, Michael S. Tsirkin [EMAIL PROTECTED] wrote:
[snip]
3e. sizeof
space after the operator
sizeof a
I don't think that's a hard rule, there's plenty of code that does
sizeof(type) and not sizeof (type), and whitespace
Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> > I'd like to have a discussion about FAT robustness.
> > Please give your thought, comments and related issues.
> What I would like is to treat completely differently writing to
> FAT (writing to a removeable drive) which need a complete "mount",
>
Etienne Lorrain [EMAIL PROTECTED] wrote:
I'd like to have a discussion about FAT robustness.
Please give your thought, comments and related issues.
What I would like is to treat completely differently writing to
FAT (writing to a removeable drive) which need a complete mount,
and just
I'm getting:
# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi
(/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device
This is definitely a Toshiba M30 notebook with this.
On bootup I see:
ACPI: RSDP (v000 TOSHIB) @ 0x000f7a10
I'm getting:
# modprobe toshiba_acpi
FATAL: Error inserting toshiba_acpi
(/lib/modules/2.6.13-rc3/kernel/drivers/acpi/toshiba_acpi.ko): No such device
This is definitely a Toshiba M30 notebook with this.
On bootup I see:
ACPI: RSDP (v000 TOSHIB) @ 0x000f7a10
Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
[...]
> Other than this, what are the general thoughts about this method as
> opposed to just using a well defined byte order?
I'd prefer a defined byte order. That way it won't bite too hard if I
happen to move a filesystem (image) from PC to
Jesse Brandeburg <[EMAIL PROTECTED]> wrote:
> On 7/13/05, Mikhail Kshevetskiy <[EMAIL PROTECTED]> wrote:
> > symptom
> > ===
> > modprobe e100
> > ifconfig eth0 netmask
> >
> > result:
> > ===
> > SIOCADDRT: Network is unreachable
> >
> > There were no such error in 2.6.13-rc2
> odd,
Jesse Brandeburg [EMAIL PROTECTED] wrote:
On 7/13/05, Mikhail Kshevetskiy [EMAIL PROTECTED] wrote:
symptom
===
modprobe e100
ifconfig eth0 ip netmask netmask
result:
===
SIOCADDRT: Network is unreachable
There were no such error in 2.6.13-rc2
odd, both e100 and
Nicholas Hans Simmonds [EMAIL PROTECTED] wrote:
[...]
Other than this, what are the general thoughts about this method as
opposed to just using a well defined byte order?
I'd prefer a defined byte order. That way it won't bite too hard if I
happen to move a filesystem (image) from PC to SPARC
Greg KH <[EMAIL PROTECTED]> wrote:
> -stable review patch. If anyone has any objections, please let us know.
> Signed-off-by: Zou Nan hai <[EMAIL PROTECTED]>
> Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>
> Cc: Andi Kleen <[EMAIL PROTECTED]>
Huh? Cc: in here?
> Signed-off-by: Andrew Morton
Nicholas Hans Simmonds <[EMAIL PROTECTED]> wrote:
> Sorry, my earlier reply seems to have gotten lost somewhere. I've been
> pondering this issue for some time and am still not sure what's the best
> answer. I've attached a small patch which handles this by detecting byte
> swapping of the version
Nicholas Hans Simmonds [EMAIL PROTECTED] wrote:
Sorry, my earlier reply seems to have gotten lost somewhere. I've been
pondering this issue for some time and am still not sure what's the best
answer. I've attached a small patch which handles this by detecting byte
swapping of the version code.
Greg KH [EMAIL PROTECTED] wrote:
-stable review patch. If anyone has any objections, please let us know.
Signed-off-by: Zou Nan hai [EMAIL PROTECTED]
Signed-off-by: Suresh Siddha [EMAIL PROTECTED]
Cc: Andi Kleen [EMAIL PROTECTED]
Huh? Cc: in here?
Signed-off-by: Andrew Morton [EMAIL
David Masover <[EMAIL PROTECTED]> wrote:
> Hans Reiser wrote:
> > Horst von Brand wrote:
> >>Hans Reiser <[EMAIL PROTECTED]> wrote:
> >>>Stefan Smietanowski wrote:
[...]
> > Better to spend one's mind looking for bugs instead of this issue
DervishD <[EMAIL PROTECTED]> wrote:
[...]
> It's a good idea to have a copy of the partition table around, if
> it is not simple (the one you had is NOT simple).
Be careful. What you'll get out of backing up the partition table is /only/
the primary partitions, the others are handled by a
David Masover [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Horst von Brand wrote:
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
[...]
Better to spend one's mind looking for bugs instead of this issue.
.if bugs were seen as such a big deal.
I think it's far
DervishD [EMAIL PROTECTED] wrote:
[...]
It's a good idea to have a copy of the partition table around, if
it is not simple (the one you had is NOT simple).
Be careful. What you'll get out of backing up the partition table is /only/
the primary partitions, the others are handled by a weird
David Masover <[EMAIL PROTECTED]> wrote:
[...]
> Both camps seem to want to allow easy access to the metadata of a
> file, whether we're given that file as an inode or as a pathname.
> That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
> to look up a file by name, and sometimes
Hans Reiser <[EMAIL PROTECTED]> wrote:
> Stefan Smietanowski wrote:
> > I think "..." and ".meta" both serve as a logical delimiter. However
> > some programs implement their own "..." which would make it clash with
> > them. Naturally if some program created a directory called .meta we're
> >
Marc Aurele La France <[EMAIL PROTECTED]> wrote:
> It has been more than a week now...
> -- Forwarded message --
> Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
> From: Marc Aurele La France <[EMAIL PROTECTED]>
> To: Linus Torvalds
> Subject: Kernel header policy
[]
> I am
Erik Hensema <[EMAIL PROTECTED]> wrote:
> Horst von Brand ([EMAIL PROTECTED]):
> [on reiserfs4]
> >> >> and _can_ do things
> >> >> no other FS can
> > Mostly useless things...
> Depends on yo
Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Sun, 10 Jul 2005, Pekka Enberg wrote:
[...]
> > Would you please be so kind to define your criteria for things that
> > "need fixing" so we could see if can reach some sort of an agreement on
> > this. My list is roughly as follows:
> >
> > -
Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 10, 2005 at 09:21:42PM +0300, Pekka Enberg wrote:
> > Hmm. So we disagree on that issue as well. I think the point of review
> > is to improve code and help others conform with the existing coding
> > style which is why I find it strange that
Erik Hensema [EMAIL PROTECTED] wrote:
Horst von Brand ([EMAIL PROTECTED]):
[on reiserfs4]
and _can_ do things
no other FS can
Mostly useless things...
Depends on your point of view. If you define things to be useful
only when POSIX
Vojtech Pavlik [EMAIL PROTECTED] wrote:
On Sun, Jul 10, 2005 at 09:21:42PM +0300, Pekka Enberg wrote:
Hmm. So we disagree on that issue as well. I think the point of review
is to improve code and help others conform with the existing coding
style which is why I find it strange that you're
Roman Zippel [EMAIL PROTECTED] wrote:
On Sun, 10 Jul 2005, Pekka Enberg wrote:
[...]
Would you please be so kind to define your criteria for things that
need fixing so we could see if can reach some sort of an agreement on
this. My list is roughly as follows:
- Erroneous use of
Marc Aurele La France [EMAIL PROTECTED] wrote:
It has been more than a week now...
-- Forwarded message --
Date: Sun, 3 Jul 2005 11:12:03 -0600 (MDT)
From: Marc Aurele La France [EMAIL PROTECTED]
To: Linus Torvalds
Subject: Kernel header policy
[]
I am contacting you
Hans Reiser [EMAIL PROTECTED] wrote:
Stefan Smietanowski wrote:
I think ... and .meta both serve as a logical delimiter. However
some programs implement their own ... which would make it clash with
them. Naturally if some program created a directory called .meta we're
equally screwed.
I
David Masover [EMAIL PROTECTED] wrote:
[...]
Both camps seem to want to allow easy access to the metadata of a
file, whether we're given that file as an inode or as a pathname.
That's why I suggested /meta/vfs and /meta/inode -- sometimes I want
to look up a file by name, and sometimes by
Ed Cogburn <[EMAIL PROTECTED]> wrote:
> David Lang wrote:
> > On Fri, 8 Jul 2005, Ed Tomlinson wrote:
> >> No Flame from me. One thing to remember is that Hans and friends
> >> _have_ supported R3 for years.
They let it fall into disrepair when they started work on 4.
> >>
Ed Cogburn [EMAIL PROTECTED] wrote:
David Lang wrote:
On Fri, 8 Jul 2005, Ed Tomlinson wrote:
No Flame from me. One thing to remember is that Hans and friends
_have_ supported R3 for years.
They let it fall into disrepair when they started work on 4.
Hans Reiser <[EMAIL PROTECTED]> wrote:
[...]
> I think the exokernel approach by Frans is a very interesting approach.
> I wish I had the experience with it necessary to know if it was
> effective. I do NOT take the position that name resolution should be in
> the kernel. I DO take the
Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs <[EMAIL PROTECTED]> said:
> > On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
> >> Hubert Chan wrote:
> >>> And a question: is it feasible to store, for each
> >>> inode, its parent(s), instead of
David Masover <[EMAIL PROTECTED]> wrote:
[...]
> Just don't allow user-created hardlinks inside either metafs (/meta) or
> the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files , and now it is severely crippled?
--
Hubert Chan <[EMAIL PROTECTED]> wrote:
> On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey <[EMAIL PROTECTED]> said:
> > Horst von Brand wrote:
> >> And who says that a normal user isn't allowed to annotate each and
> >> every file with its purpose or somet
Hubert Chan [EMAIL PROTECTED] wrote:
On Fri, 01 Jul 2005 03:41:00 -0400, Chet Hosey [EMAIL PROTECTED] said:
Horst von Brand wrote:
And who says that a normal user isn't allowed to annotate each and
every file with its purpose or something else?
Explain how you currently allow users
David Masover [EMAIL PROTECTED] wrote:
[...]
Just don't allow user-created hardlinks inside either metafs (/meta) or
the magical meta directory inside files.
And what is it useful for, after its advantage was that it was /exactly/
like regular files c, and now it is severely crippled?
--
Dr.
Hubert Chan [EMAIL PROTECTED] wrote:
On Wed, 06 Jul 2005 12:52:23 -0600, Jonathan Briggs [EMAIL PROTECTED] said:
On Tue, 2005-07-05 at 23:44 -0700, Hans Reiser wrote:
Hubert Chan wrote:
And a question: is it feasible to store, for each
inode, its parent(s), instead of just the hard link
Hans Reiser [EMAIL PROTECTED] wrote:
[...]
I think the exokernel approach by Frans is a very interesting approach.
I wish I had the experience with it necessary to know if it was
effective. I do NOT take the position that name resolution should be in
the kernel. I DO take the position
Xin Zhao <[EMAIL PROTECTED]> wrote:
> I tried to do "insmod nfsd.ko", but always got the error message
> "insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module"
Use modprobe(8), it knows about module dependencies and what to load.
--
Dr. Horst H. von Brand User #22616
Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> > > > > NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
> > > > > include gcc version in your reports.
> > > >
> > > > But this can't occur in the kernel.
> > >
> > > It can. I saw the OOPS myself.
> > > One of the functions in
Denis Vlasenko [EMAIL PROTECTED] wrote:
NB: gcc 3.4.3 can use excessive stack in degenerate cases, so please
include gcc version in your reports.
But this can't occur in the kernel.
It can. I saw the OOPS myself.
One of the functions in crypto/wp512.c was compiled with
Xin Zhao [EMAIL PROTECTED] wrote:
I tried to do insmod nfsd.ko, but always got the error message
insmod: error inserting 'nfsd.ko': -1 Unknown symbol in module
Use modprobe(8), it knows about module dependencies and what to load.
--
Dr. Horst H. von Brand User #22616
David Masover <[EMAIL PROTECTED]> wrote:
> Horst von Brand wrote:
> > David Masover <[EMAIL PROTECTED]> wrote:
> >>David Weinehall wrote:
> >>>On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
> >>>>David Weinehall wrote:
[
David Masover [EMAIL PROTECTED] wrote:
Horst von Brand wrote:
David Masover [EMAIL PROTECTED] wrote:
David Weinehall wrote:
On Fri, Jul 01, 2005 at 03:08:58AM -0500, David Masover wrote:
David Weinehall wrote:
[...]
Even if they don't, it would be more beneficial to me
How, exactly
Petr Baudis <[EMAIL PROTECTED]> said:
[...]
> The way to work around that is to setup separate rsync URIs for each of
> the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
> in form
>
> rsync://host/path!branchname
>
> which will allow you to select the particular
Petr Baudis [EMAIL PROTECTED] said:
[...]
The way to work around that is to setup separate rsync URIs for each of
the trees. ;-) I think I will make git-pasky (Cogito) accept also URIs
in form
rsync://host/path!branchname
which will allow you to select the particular branch in the
Andreas Hartmann <[EMAIL PROTECTED]> said:
> Alacritech developed a new chip for NIC's
> (http://www.alacritech.com/html/tech_review.html), which makes it possible
> to take away the TCP stack from the host CPU. Therefore, the host CPU has
> more performance for the applications according
Andreas Hartmann [EMAIL PROTECTED] said:
Alacritech developed a new chip for NIC's
(http://www.alacritech.com/html/tech_review.html), which makes it possible
to take away the TCP stack from the host CPU. Therefore, the host CPU has
more performance for the applications according Alacritech.
"Franco \"Sensei\"" <[EMAIL PROTECTED]> said:
> David Lang wrote:
> > some config changes are additions, some redefine things.
> >
> > you are mistakeing the .config file for a symbol table.
> No I'm not confusing. As long as the .config has an influence on the
> makefiles I get different
Franco \Sensei\ [EMAIL PROTECTED] said:
David Lang wrote:
some config changes are additions, some redefine things.
you are mistakeing the .config file for a symbol table.
No I'm not confusing. As long as the .config has an influence on the
makefiles I get different symbols names.
[EMAIL PROTECTED] said:
> As per http://www.nist.gov/dads/HTML/shellsort.html, this should be
> referred to as a Shell sort. Shell-Metzner is a misnomer.
> Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]>
> Signed-off-by: Domen Puncer <[EMAIL PROTECTED]>
Why not use the sort routine from
[EMAIL PROTECTED] said:
As per http://www.nist.gov/dads/HTML/shellsort.html, this should be
referred to as a Shell sort. Shell-Metzner is a misnomer.
Signed-off-by: Daniel Dickman [EMAIL PROTECTED]
Signed-off-by: Domen Puncer [EMAIL PROTECTED]
Why not use the sort routine from lib/sort.c?
AsterixTheGaul <[EMAIL PROTECTED]> said:
> > -#define module_init(x) __initcall(x);
> > +#define module_init(x) __initcall(x); __module_init_disable(x);
>
> It would be better if there is brackets around them... like
>
> #define module_init(x) { __initcall(x); __module_init_disable(x); }
>
>
AsterixTheGaul [EMAIL PROTECTED] said:
-#define module_init(x) __initcall(x);
+#define module_init(x) __initcall(x); __module_init_disable(x);
It would be better if there is brackets around them... like
#define module_init(x) { __initcall(x); __module_init_disable(x); }
then we know
Sven Luther <[EMAIL PROTECTED]> said:
> On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
> > Humberto Massa wrote:
> > >But, the question made here was a subtler one and you are all biting
> > >around the bush: there *are* some misrepresentations of licenses to the
> > >firmware
Sven Luther [EMAIL PROTECTED] said:
On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
Humberto Massa wrote:
But, the question made here was a subtler one and you are all biting
around the bush: there *are* some misrepresentations of licenses to the
firmware blobs in the
Jonas Diemer <[EMAIL PROTECTED]> said:
[...]
> I figured there could be a kernel compiled-in option that will make the
> kernel lock all drives found during bootup. then, a malicous program
> would need to install a different kernel in order to harm the drive,
> which would be much more secure.
Wiktor <[EMAIL PROTECTED]> said:
> Horst von Brand wrote:
> > Even better: Write a C wrapper for each affected program that just renices
> > it as needed.
> I suggest to implement scalable solution, so the final user wont't have
> to write separate wrapper for *each* p
Wiktor [EMAIL PROTECTED] said:
Horst von Brand wrote:
Even better: Write a C wrapper for each affected program that just renices
it as needed.
I suggest to implement scalable solution, so the final user wont't have
to write separate wrapper for *each* program.
Final user doesn't
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= <[EMAIL PROTECTED]> said:
> Wiktor <[EMAIL PROTECTED]> writes:
[...]
> > max renice ulimit is quite good idea, but it allows to change nice of
> > *any* process user has permissions to. it could be implemented also,
> > but the idea of 'nice' file attribute is
=?iso-8859-1?q?M=E5ns_Rullg=E5rd?= [EMAIL PROTECTED] said:
Wiktor [EMAIL PROTECTED] writes:
[...]
max renice ulimit is quite good idea, but it allows to change nice of
*any* process user has permissions to. it could be implemented also,
but the idea of 'nice' file attribute is to allow
"Jean Delvare" <[EMAIL PROTECTED]> said:
> > > > No, there is a third case: the pointer can be NULL, but the compiler
> > > > happened to move the dereference down to after the check.
> > > Wow. Great point. I completely missed that possibility. In fact I didn't
> > > know that the compiler could
Jean Delvare [EMAIL PROTECTED] said:
No, there is a third case: the pointer can be NULL, but the compiler
happened to move the dereference down to after the check.
Wow. Great point. I completely missed that possibility. In fact I didn't
know that the compiler could possibly alter
"Jean Delvare" <[EMAIL PROTECTED]> said:
[Sttributions missing, sorry]
> > > Think about it. If the pointer could be NULL, then it's unlikely that
> > > the bug would have gone unnoticed so far (unless the code is very
> > > recent). Coverity found 3 such bugs in one i2c driver [1], and the
>
1 - 100 of 553 matches
Mail list logo
