Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
> kcalloc does have value, in that it's a nice api to avoid multiplication
> overflows. Just for "1" it's indeed not the most useful API.
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it for the kernel? Is
Hi,
On Thu, 4 Aug 2005, Andrew Morton wrote:
> > +static inline void *kzalloc(size_t size, unsigned int __nocast flags)
> > +{
> > + return kcalloc(1, size, flags);
> > +}
> > +
>
> That'll generate just as much code as simply using kcalloc(1, ...). This
> function should be out-of-line and
Hi,
On Thu, 4 Aug 2005, Andrew Morton wrote:
+static inline void *kzalloc(size_t size, unsigned int __nocast flags)
+{
+ return kcalloc(1, size, flags);
+}
+
That'll generate just as much code as simply using kcalloc(1, ...). This
function should be out-of-line and
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
kcalloc does have value, in that it's a nice api to avoid multiplication
overflows. Just for 1 it's indeed not the most useful API.
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it for the kernel? Is
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
This would imply a similiar kmalloc() would be useful as well.
Second, how relevant is it for the kernel?
we've had a non-negliable amount of security holes because of this
So why don't we have a similiar kmalloc()?
Is that really the
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
we've had a non-negliable amount of security holes because of this
So why don't we have a similiar kmalloc()?
nope kmalloc is not an array allocator
it makes it easy and safe. Of course you can and should check it in all
users.
Hi,
On Fri, 5 Aug 2005, Arjan van de Ven wrote:
Maybe it helps if I give the basic bug scenario first (pseudo C)
void some_ioctl_func(...)
{
int count, i;
struct foo *ptr;
copy_from_user(count,...);
ptr = kmalloc(sizeof(struct foo) * count);
if (!ptr)
return
Hi,
On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
> > What makes you think the comment is correct? This comment was added at
> > 2.4.3, while schedule_timeout() has this behaviour since it was added at
> > 2.1.127.
>
> Fair enough. Should we change the comment?
It can't hurt to fix the
Hi,
On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
> The comment for schedule_timeout() claims:
>
> * Make the current task sleep until @timeout jiffies have
> * elapsed.
>
> Currently, it does not do so. I was simply trying to make the function
> do what it claims it does.
What makes you
Hi,
Andrew, please drop this patch.
Nish, please stop fucking around with kernel APIs.
On Wed, 3 Aug 2005, Nishanth Aravamudan wrote:
> > The "jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1)" case (when the
> > process is immediately woken up again) makes the caller suspectible to
> >
Hi,
Andrew, please drop this patch.
Nish, please stop fucking around with kernel APIs.
On Wed, 3 Aug 2005, Nishanth Aravamudan wrote:
The jiffies_to_msecs(msecs_to_jiffies(timeout_msecs) + 1) case (when the
process is immediately woken up again) makes the caller suspectible to
timeout
Hi,
On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
The comment for schedule_timeout() claims:
* Make the current task sleep until @timeout jiffies have
* elapsed.
Currently, it does not do so. I was simply trying to make the function
do what it claims it does.
What makes you think
Hi,
On Thu, 4 Aug 2005, Nishanth Aravamudan wrote:
What makes you think the comment is correct? This comment was added at
2.4.3, while schedule_timeout() has this behaviour since it was added at
2.1.127.
Fair enough. Should we change the comment?
It can't hurt to fix the comment.
Hi,
On Mon, 1 Aug 2005, Nishanth Aravamudan wrote:
> +unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
> +{
> + unsigned long expire_jifs;
> +
> + if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
> + expire_jifs = MAX_SCHEDULE_TIMEOUT;
> + } else
Hi,
On Mon, 1 Aug 2005, Nishanth Aravamudan wrote:
+unsigned int __sched schedule_timeout_msecs(unsigned int timeout_msecs)
+{
+ unsigned long expire_jifs;
+
+ if (timeout_msecs == MAX_SCHEDULE_TIMEOUT_MSECS) {
+ expire_jifs = MAX_SCHEDULE_TIMEOUT;
+ } else {
+
Hi,
On Tue, 2 Aug 2005, Lee Revell wrote:
> On Tue, 2005-08-02 at 13:23 +0200, Pavel Machek wrote:
> > As I said, I do not care about default value. And you should not care,
> > too, since distros are likely to pick their own defaults.
>
> If the default value does not matter then the default
Hi,
On Tue, 2 Aug 2005, Lee Revell wrote:
On Tue, 2005-08-02 at 13:23 +0200, Pavel Machek wrote:
As I said, I do not care about default value. And you should not care,
too, since distros are likely to pick their own defaults.
If the default value does not matter then the default should
Hi,
On Sun, 31 Jul 2005, Sam Ravnborg wrote:
> In a couple of cases I have had the need to include a Kconfig file only
> if present.
> The current 'source' directive works as one would expect. It bails out
> if the file is missing.
I don't really like it, it's an open invitation to abuse.
I'd
Hi,
On Wed, 27 Jul 2005, Nishanth Aravamudan wrote:
> > > My goal is to distinguish between these cases in sleeping-logic:
> > >
> > > 1) tick-oriented
> > > use schedule_timeout(), add_timer(), etc.
> > >
> > > 2) time-oriented
> > > use schedule_timeout_msecs()
> >
> > There is _no_
Hi,
On Wed, 27 Jul 2005, Nishanth Aravamudan wrote:
My goal is to distinguish between these cases in sleeping-logic:
1) tick-oriented
use schedule_timeout(), add_timer(), etc.
2) time-oriented
use schedule_timeout_msecs()
There is _no_ difference, the scheduler is
Hi,
On Sun, 31 Jul 2005, Sam Ravnborg wrote:
In a couple of cases I have had the need to include a Kconfig file only
if present.
The current 'source' directive works as one would expect. It bails out
if the file is missing.
I don't really like it, it's an open invitation to abuse.
I'd
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > What's wrong with just:
> >
> >
> > schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
>
> Nothing, I suppose. I just prefer directly using msecs. I understand
> your point more now, I think. You are worried
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > Jiffies are the basic time unit for kernel timers, hiding that fact gives
> > users only wrong expectations about them.
>
> We already have msleep() and msleep_interruptible(), which hide jiffies
> in milliseconds. These interfaces are
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> > Keep the thing as simple as possible and jiffies _are_ simple. Please show
> > me the problem, that needs to be fixed.
>
> I am not sure why jiffies are any simpler than milliseconds. In the
> millisecond case, conversion happens in
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
> set_current_state(TASK_{,UN}INTERRUPTIBLE);
> schedule_timeout(msecs_to_jiffies(some_constant_msecs));
>
> just have an interface that allows
>
> schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
>
> and
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > jiffies/HZ is the more powerful API. The msec one which also sets
> > > current to (un)interruptible is the simplified wrapper on top.
> >
> > So why do you want to hide it?
>
> I don't want to hide it at all. I want to provide a simpler
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> jiffies/HZ is the more powerful API. The msec one which also sets
> current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based API the primary one
and add some convenience functions,
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > > > What's wrong with using jiffies?
> > >
> > > A lot of the (driver) users want a wallclock based timeout. For that,
> > > miliseconds is a more obvious API with less chance to get the jiffies/HZ
> > > conversion wrong by the driver
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
> > What's wrong with using jiffies?
>
> A lot of the (driver) users want a wallclock based timeout. For that,
> miliseconds is a more obvious API with less chance to get the jiffies/HZ
> conversion wrong by the driver writer.
We have helper
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
> Also I'd rather not add the non-msec ones... either you're raw and use
> HZ, or you are "cooked" and use the msec variant.. I dont' see the point
> of adding an "in the middle" one. (Yes this means that several users
> need to be transformed to
Hi,
On Fri, 22 Jul 2005, Arjan van de Ven wrote:
Also I'd rather not add the non-msec ones... either you're raw and use
HZ, or you are cooked and use the msec variant.. I dont' see the point
of adding an in the middle one. (Yes this means that several users
need to be transformed to msecs
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
conversion wrong by the driver writer.
We have helper
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
What's wrong with using jiffies?
A lot of the (driver) users want a wallclock based timeout. For that,
miliseconds is a more obvious API with less chance to get the jiffies/HZ
conversion wrong by the driver writer.
We have
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it? Make the jiffies based API the primary one
and add some convenience functions,
Hi,
On Sat, 23 Jul 2005, Arjan van de Ven wrote:
jiffies/HZ is the more powerful API. The msec one which also sets
current to (un)interruptible is the simplified wrapper on top.
So why do you want to hide it?
I don't want to hide it at all. I want to provide a simpler variant for
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
set_current_state(TASK_{,UN}INTERRUPTIBLE);
schedule_timeout(msecs_to_jiffies(some_constant_msecs));
just have an interface that allows
schedule_timeout_msecs_{,un}interruptible(some_constant_msecs);
and push the
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
Keep the thing as simple as possible and jiffies _are_ simple. Please show
me the problem, that needs to be fixed.
I am not sure why jiffies are any simpler than milliseconds. In the
millisecond case, conversion happens in common code
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
Jiffies are the basic time unit for kernel timers, hiding that fact gives
users only wrong expectations about them.
We already have msleep() and msleep_interruptible(), which hide jiffies
in milliseconds. These interfaces are their
Hi,
On Sat, 23 Jul 2005, Nishanth Aravamudan wrote:
What's wrong with just:
schedule_timeout_{,un}interruptible(msecs_to_jiffies(some_constant_msecs));
Nothing, I suppose. I just prefer directly using msecs. I understand
your point more now, I think. You are worried about those
Hi,
On Wed, 20 Jul 2005, john stultz wrote:
> I really don't think the NTP changes I've mailed is very complex.
> Please, be specific and point to something you think is an issue and
> I'll do my best to fix it.
Maybe I should explain, in what direction I would take it.
Let's first only take
Hi,
On Wed, 20 Jul 2005, john stultz wrote:
I really don't think the NTP changes I've mailed is very complex.
Please, be specific and point to something you think is an issue and
I'll do my best to fix it.
Maybe I should explain, in what direction I would take it.
Let's first only take tick
Hi,
On Mon, 18 Jul 2005, Karim Yaghmour wrote:
> I guess I just don't get the point here. Why cut something away if many
> users will need it. If it's that popular that you're ready to provide a
> library function to do it, then why not just leave it to boot? One of the
> goals of relayfs is to
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
> > What exactly would be slowed down?
> > It would just move around some code and even avoid the overwrite mode
> > check.
>
> Yes, you're adding a jump to another function via a function pointer,
> that would kill the cache line of execution, to
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
> I'm actually very much against this. Looking at a point of view from the
> logdev device. Having a callback to know to continue at every buffer
> switch would just be slowing down something that is expected to be very
> fast.
What exactly would
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
I'm actually very much against this. Looking at a point of view from the
logdev device. Having a callback to know to continue at every buffer
switch would just be slowing down something that is expected to be very
fast.
What exactly would be
Hi,
On Mon, 18 Jul 2005, Steven Rostedt wrote:
What exactly would be slowed down?
It would just move around some code and even avoid the overwrite mode
check.
Yes, you're adding a jump to another function via a function pointer,
that would kill the cache line of execution, to avoid a
Hi,
On Mon, 18 Jul 2005, Karim Yaghmour wrote:
I guess I just don't get the point here. Why cut something away if many
users will need it. If it's that popular that you're ready to provide a
library function to do it, then why not just leave it to boot? One of the
goals of relayfs is to
Hi,
On Fri, 15 Jul 2005, john stultz wrote:
> In my attempts to rework the timeofday subsystem, it was suggested I
> try to avoid mixing cleanups with functional changes. In response to the
> suggestion I've tried to break out the majority of the NTP cleanups I've
> been working out of my
Hi,
On Thu, 14 Jul 2005, Tom Zanussi wrote:
> The netlink control channel seems to work very well, but I can
> certainly change the examples to use something different. Could you
> suggest something?
It just looks like a complicated way to do an ioctl, a control file that
you can read/write
Hi,
On Sun, 17 Jul 2005, Bodo Eggert wrote:
> These patches change some menus into menuconfig options.
>
> Reworked to apply to linux-2.6.13-rc3-git3
I like it, but I would prefer to give it first a bit more exposure in -mm,
as it does change the menu structure and the behaviour is little
Hi,
On Sun, 17 Jul 2005, Bodo Eggert wrote:
These patches change some menus into menuconfig options.
Reworked to apply to linux-2.6.13-rc3-git3
I like it, but I would prefer to give it first a bit more exposure in -mm,
as it does change the menu structure and the behaviour is little
Hi,
On Thu, 14 Jul 2005, Tom Zanussi wrote:
The netlink control channel seems to work very well, but I can
certainly change the examples to use something different. Could you
suggest something?
It just looks like a complicated way to do an ioctl, a control file that
you can read/write
Hi,
On Fri, 15 Jul 2005, john stultz wrote:
In my attempts to rework the timeofday subsystem, it was suggested I
try to avoid mixing cleanups with functional changes. In response to the
suggestion I've tried to break out the majority of the NTP cleanups I've
been working out of my
Hi,
On Thu, 14 Jul 2005, Nishanth Aravamudan wrote:
> We no longer use jiffies (the variable) as the basis for determining
> what "time" a timer should expire or when it should be added. Instead,
> we use a new function, do_monotonic_clock(), which is simply a wrapper
> for getnstimeofday().
Hi,
On Mon, 11 Jul 2005, Andrew Morton wrote:
> > > Hi Andrew, can you please merge relayfs? It provides a low-overhead
> > > logging and buffering capability, which does not currently exist in
> > > the kernel.
> >
> > While the code is pretty nicely in shape it seems rather pointless to
> >
Hi,
On Mon, 11 Jul 2005, Andrew Morton wrote:
Hi Andrew, can you please merge relayfs? It provides a low-overhead
logging and buffering capability, which does not currently exist in
the kernel.
While the code is pretty nicely in shape it seems rather pointless to
merge until an
Hi,
On Thu, 14 Jul 2005, Nishanth Aravamudan wrote:
We no longer use jiffies (the variable) as the basis for determining
what time a timer should expire or when it should be added. Instead,
we use a new function, do_monotonic_clock(), which is simply a wrapper
for getnstimeofday().
And
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> The following patches complete the "Kconfig I18N support" patch by
> Arnaldo.
First I'd really like to see some documentation on this, which describes
the interface how tools/distributions can provide Kconfig I18N support.
> - answering (Y/M/N)
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> UTF-8 support for lxdialog with wchar. The installed wide ncurses
> (ncursesw) is optional because some languages (ex. English, Italian)
> and ISO 8859-xx charsets don't require this patch.
This is ugly, this just adds lots of #ifdefs with
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
> diff -puN scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
> scripts/kconfig/zconf.l
> ---
> linux-2.6.13-rc3-i18n-kconfig/scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
> 2005-07-13 18:32:20.0 +0200
> +++
Hi,
On Tue, 12 Jul 2005, randy_dunlap wrote:
> This appears to be a dependency bug in gconfig to me.
>
> If I enable NETCONSOLE to y, NETPOLL becomes y. (OK)
> If I then disable NETCONSOLE to n, NETPOLL remains y.
>
> If I enable NETCONSOLE to m, NETPOLL remains n. Why is that?
>
> config
Hi,
On Tue, 12 Jul 2005, randy_dunlap wrote:
This appears to be a dependency bug in gconfig to me.
If I enable NETCONSOLE to y, NETPOLL becomes y. (OK)
If I then disable NETCONSOLE to n, NETPOLL remains y.
If I enable NETCONSOLE to m, NETPOLL remains n. Why is that?
config NETPOLL
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
diff -puN scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
scripts/kconfig/zconf.l
---
linux-2.6.13-rc3-i18n-kconfig/scripts/kconfig/zconf.l~kconfig-i18n-18-whitespace-fix
2005-07-13 18:32:20.0 +0200
+++
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
UTF-8 support for lxdialog with wchar. The installed wide ncurses
(ncursesw) is optional because some languages (ex. English, Italian)
and ISO 8859-xx charsets don't require this patch.
This is ugly, this just adds lots of #ifdefs with practically
Hi,
On Wed, 13 Jul 2005, Egry G�bor wrote:
The following patches complete the Kconfig I18N support patch by
Arnaldo.
First I'd really like to see some documentation on this, which describes
the interface how tools/distributions can provide Kconfig I18N support.
- answering (Y/M/N)
This
Hi,
On Mon, 11 Jul 2005, Horst von Brand wrote:
> > I don't generally disagree with that, I just think that defines are not
> > part of that list.
>
> Covered in "bad coding style" and "hard to read code", at least.
Somehow I missed the last lkml debate about where simple defines where a
Hi,
On Mon, 11 Jul 2005, Horst von Brand wrote:
I don't generally disagree with that, I just think that defines are not
part of that list.
Covered in bad coding style and hard to read code, at least.
Somehow I missed the last lkml debate about where simple defines where a
problem.
Hi,
On Sun, 10 Jul 2005, Pekka Enberg wrote:
> > The point of a review is to comment on things that _need_ fixing. Less
> > experienced hackers take this a requirement for their drivers to be
> > included.
>
> Hmm. So we disagree on that issue as well. I think the point of review
> is to
Hi,
On Sun, 10 Jul 2005, Pekka Enberg wrote:
The point of a review is to comment on things that _need_ fixing. Less
experienced hackers take this a requirement for their drivers to be
included.
Hmm. So we disagree on that issue as well. I think the point of review
is to improve code
Hi,
On Sat, 9 Jul 2005, Bodo Eggert wrote:
> On Sat, 9 Jul 2005, Adrian Bunk wrote:
> > On Mon, Jul 04, 2005 at 04:59:18PM +0200, Bodo Eggert wrote:
>
> ...
> > > Therefore I can't use
> > > config SGI_IOC4
> > > tristate
> > > prompt "SGI IOC4 Base IO support" if
Hi,
On Sat, 9 Jul 2005, Bodo Eggert wrote:
On Sat, 9 Jul 2005, Adrian Bunk wrote:
On Mon, Jul 04, 2005 at 04:59:18PM +0200, Bodo Eggert wrote:
...
Therefore I can't use
config SGI_IOC4
tristate
prompt SGI IOC4 Base IO support if PROMPT_FOR_UNUSED_CORES
depends on
Hi,
On Fri, 8 Jul 2005, Adrian Bunk wrote:
> --- linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig.old 2005-07-02
> 21:57:40.0 +0200
> +++ linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig 2005-07-02 21:58:06.0
> +0200
> @@ -447,7 +447,7 @@
> source
Hi,
On Fri, 8 Jul 2005, Pekka Enberg wrote:
> On Fri, 2005-07-08 at 21:11 +0200, Roman Zippel wrote:
> > So it basically comes down to personal preference, if the original uses
> > defines and it works fine, I don't really see a good enough reason to
> > change it to e
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
> I don't see how the following is tortured:
> enum {
> PNODE_MEMBER_VFS = 0x01,
> PNODE_SLAVE_VFS = 0x02
> };
> In fact, I think it is more natural. An almost identical example even appears
> in K
So it basically comes down to
Hi,
On Fri, 8 Jul 2005, Bryan Henderson wrote:
> I wasn't aware anyone preferred defines to enums for declaring enumerated
> data types.
If it's really enumerated data types, that's fine, but this example was
about bitfield masks.
> Isn't the only argument for defines, "that's what I'm used
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
> > You can't do that with defines?
>
> Sure you can but have you ever tried to figure out where a group of #define
> enumerations end?
Comments? Newlines?
> Enums are a natural language construct for grouping related
> constants so why not use
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
> On Fri, 8 Jul 2005, Pekka Enberg wrote:
> > > > +#define PNODE_MEMBER_VFS 0x01
> > > > +#define PNODE_SLAVE_VFS 0x02
> > > > Enums, please.
>
> Roman Zippel writes:
> > Is this becoming
Hi,
On Fri, 8 Jul 2005, Pekka Enberg wrote:
> > +#define PNODE_MEMBER_VFS 0x01
> > +#define PNODE_SLAVE_VFS 0x02
>
> Enums, please.
Is this becoming a requirement now? I personally would rather leave that
to personal preference...
bye, Roman
-
To unsubscribe from this list: send the line
Hi,
On Fri, 8 Jul 2005, Pekka Enberg wrote:
+#define PNODE_MEMBER_VFS 0x01
+#define PNODE_SLAVE_VFS 0x02
Enums, please.
Is this becoming a requirement now? I personally would rather leave that
to personal preference...
bye, Roman
-
To unsubscribe from this list: send the line
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
On Fri, 8 Jul 2005, Pekka Enberg wrote:
+#define PNODE_MEMBER_VFS 0x01
+#define PNODE_SLAVE_VFS 0x02
Enums, please.
Roman Zippel writes:
Is this becoming a requirement now? I personally would rather leave that to
personal
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
You can't do that with defines?
Sure you can but have you ever tried to figure out where a group of #define
enumerations end?
Comments? Newlines?
Enums are a natural language construct for grouping related
constants so why not use it?
So
Hi,
On Fri, 8 Jul 2005, Bryan Henderson wrote:
I wasn't aware anyone preferred defines to enums for declaring enumerated
data types.
If it's really enumerated data types, that's fine, but this example was
about bitfield masks.
Isn't the only argument for defines, that's what I'm used to.?
Hi,
On Fri, 8 Jul 2005, Pekka J Enberg wrote:
I don't see how the following is tortured:
enum {
PNODE_MEMBER_VFS = 0x01,
PNODE_SLAVE_VFS = 0x02
};
In fact, I think it is more natural. An almost identical example even appears
in KR.
So it basically comes down to personal
Hi,
On Fri, 8 Jul 2005, Pekka Enberg wrote:
On Fri, 2005-07-08 at 21:11 +0200, Roman Zippel wrote:
So it basically comes down to personal preference, if the original uses
defines and it works fine, I don't really see a good enough reason to
change it to enums, so please leave
Hi,
On Fri, 8 Jul 2005, Adrian Bunk wrote:
--- linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig.old 2005-07-02
21:57:40.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig 2005-07-02 21:58:06.0
+0200
@@ -447,7 +447,7 @@
source drivers/scsi/megaraid/Kconfig.megaraid
Hi,
On Mon, 4 Jul 2005, Adrian Bunk wrote:
> --- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old2005-07-02
> 20:07:25.0 +0200
> +++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig2005-07-02
> 20:13:05.0 +0200
> @@ -58,8 +58,9 @@
> depends on IP_ADVANCED_ROUTER
>
Hi,
On Mon, 4 Jul 2005, Kurt Wall wrote:
> --- a/scripts/lxdialog/Makefile 2005-07-04 09:54:44.0 -0400
> +++ b/scripts/lxdialog/Makefile 2005-07-04 11:50:00.0 -0400
> @@ -35,8 +35,11 @@
> echo -e "\007" ;\
> echo ">> Unable to find the
Hi,
On Mon, 4 Jul 2005, Adrian Bunk wrote:
--- linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig.old2005-07-02
20:07:25.0 +0200
+++ linux-2.6.13-rc1-mm1-full/net/ipv4/Kconfig2005-07-02
20:13:05.0 +0200
@@ -58,8 +58,9 @@
depends on IP_ADVANCED_ROUTER
Hi,
On Mon, 4 Jul 2005, Kurt Wall wrote:
--- a/scripts/lxdialog/Makefile 2005-07-04 09:54:44.0 -0400
+++ b/scripts/lxdialog/Makefile 2005-07-04 11:50:00.0 -0400
@@ -35,8 +35,11 @@
echo -e \007 ;\
echo Unable to find the Ncurses
Al Viro wrote:
> thread_info, part 1:
Patches look fine. Some of the helper stuff could be moved to
asm-generic, but that can still be done later. The headers really need
some serious cleanup in this area, the dependencies are damned fragile.
I8 still have a completely untested patch to
Hi,
On Sat, 23 Apr 2005, Adrian Bunk wrote:
> Currently, DEBUG_BUGVERBOSE, is automatically set to "y" if
> DEBUG_KERNEL=n and EMBEDDED=y which doesn't make much sense.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> --- linux-2.6.12-rc2-mm3-full/lib/Kconfig.debug.old 2005-04-22
>
Hi,
On Sat, 23 Apr 2005, Adrian Bunk wrote:
Currently, DEBUG_BUGVERBOSE, is automatically set to y if
DEBUG_KERNEL=n and EMBEDDED=y which doesn't make much sense.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
--- linux-2.6.12-rc2-mm3-full/lib/Kconfig.debug.old 2005-04-22
Al Viro wrote:
thread_info, part 1:
Patches look fine. Some of the helper stuff could be moved to
asm-generic, but that can still be done later. The headers really need
some serious cleanup in this area, the dependencies are damned fragile.
I8 still have a completely untested patch to
Hi,
On Wed, 20 Apr 2005, Colin Leroy wrote:
> for some reason yet unknown, fsck.hfsplus doesn't correctly set the
> HFSPLUS_VOL_UNMNT flag here.
If fsck doesn't mark it clean, there must be a reason and that also means
you shouldn't mount it writable.
bye, Roman
-
To unsubscribe from this
Hi,
On Wed, 20 Apr 2005, Colin Leroy wrote:
for some reason yet unknown, fsck.hfsplus doesn't correctly set the
HFSPLUS_VOL_UNMNT flag here.
If fsck doesn't mark it clean, there must be a reason and that also means
you shouldn't mount it writable.
bye, Roman
-
To unsubscribe from this
Hi,
On Sun, 10 Apr 2005, Paul P Komkoff Jr wrote:
> (borrowed from Tommi Virtanen)
>
> Code snippet to reconstruct ancestry graph from bk repo:
> bk changes -end':I: $if(:PARENT:){:PARENT:$if(:MPARENT:){ :MPARENT:}}
> $unless(:PARENT:){-}' |tac
>
> format is:
> newrev parent1
Hi,
On Sun, 10 Apr 2005, Paul P Komkoff Jr wrote:
(borrowed from Tommi Virtanen)
Code snippet to reconstruct ancestry graph from bk repo:
bk changes -end':I: $if(:PARENT:){:PARENT:$if(:MPARENT:){ :MPARENT:}}
$unless(:PARENT:){-}' |tac
format is:
newrev parent1 [parent2]
Hi,
On Sat, 9 Apr 2005, Eric D. Mudama wrote:
> > For example bk does something like this:
> >
> > A1 -> A2 -> A3 -> BM
> > \-> B1 -> B2 --^
> >
> > and instead of creating the merge changeset, one could merge them like
> > this:
> >
> > A1 -> A2 -> A3 -> B1 -> B2
>
Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
> Yes. Per-file history is expensive in git, because if the way it is
> indexed. Things are indexed by tree and by changeset, and there are no
> per-file indexes.
>
> You could create per-file _caches_ (*) on top of git if you wanted to make
> it
Hi,
On Fri, 8 Apr 2005, Linus Torvalds wrote:
> Also, I suspect that BKCVS actually bothers to get more details out of a
> BK tree than I cared about. People have pestered Larry about it, so BKCVS
> exports a lot of the nitty-gritty (per-file comments etc) that just
> doesn't actually _matter_,
701 - 800 of 1055 matches
Mail list logo
