Re: [PATCH] Optimize is_power_of_2().
On Fri, 15 Jun 2007 14:54:20 -0500
"David M. Lloyd" <[EMAIL PROTECTED]> wrote:
> On Fri, 15 Jun 2007 21:47:50 +0200 (CEST)
> Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> > On Jun 15 2007 18:56, Vegard Nossum wrote:
> > > bool is_power_of_2(unsigned long n)
> > > {
> > >- return (n != 0 && ((n & (n - 1)) == 0));
> > >+ return n * !(n & (n - 1));
> > > }
> >
> > There is a third way which uses neither * nor &&, but []:
>
> I assume using something GCC-specific is right out?
>
> bool is_power_of_to(unsigned long n)
> {
> return __builtin_ffsl(n) == 1;
Pretend I typed this instead:
bool is_power_of_2(unsigned long n)
{
return __builtin_popcountl(n) == 1;
}
All I can say is, it's really hot here :P
- DML
-
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/
Re: [PATCH] Optimize is_power_of_2().
On Fri, 15 Jun 2007 21:47:50 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Jun 15 2007 18:56, Vegard Nossum wrote:
> > bool is_power_of_2(unsigned long n)
> > {
> >-return (n != 0 && ((n & (n - 1)) == 0));
> >+return n * !(n & (n - 1));
> > }
>
> There is a third way which uses neither * nor &&, but []:
I assume using something GCC-specific is right out?
bool is_power_of_to(unsigned long n)
{
return __builtin_ffsl(n) == 1;
}
- DML
-
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/
Re: [PATCH] Optimize is_power_of_2().
On Fri, 15 Jun 2007 21:47:50 +0200 (CEST)
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 15 2007 18:56, Vegard Nossum wrote:
bool is_power_of_2(unsigned long n)
{
-return (n != 0 ((n (n - 1)) == 0));
+return n * !(n (n - 1));
}
There is a third way which uses neither * nor , but []:
I assume using something GCC-specific is right out?
bool is_power_of_to(unsigned long n)
{
return __builtin_ffsl(n) == 1;
}
- DML
-
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/
Re: [PATCH] Optimize is_power_of_2().
On Fri, 15 Jun 2007 14:54:20 -0500
David M. Lloyd [EMAIL PROTECTED] wrote:
On Fri, 15 Jun 2007 21:47:50 +0200 (CEST)
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jun 15 2007 18:56, Vegard Nossum wrote:
bool is_power_of_2(unsigned long n)
{
- return (n != 0 ((n (n - 1)) == 0));
+ return n * !(n (n - 1));
}
There is a third way which uses neither * nor , but []:
I assume using something GCC-specific is right out?
bool is_power_of_to(unsigned long n)
{
return __builtin_ffsl(n) == 1;
Pretend I typed this instead:
bool is_power_of_2(unsigned long n)
{
return __builtin_popcountl(n) == 1;
}
All I can say is, it's really hot here :P
- DML
-
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/
Re: Syslets, Threadlets, generic AIO support, v6
On Wed, 30 May 2007 14:27:52 -0700 (PDT) Linus Torvalds <[EMAIL PROTECTED]> wrote: > Well, don't think of it as a special case at all: think of bit 30 as > a "the user asked for a non-linear fd". If the sole point is to protect an fd from being closed or operated on outside of a certain context, why not just provide the ability to "protect" an fd to prevent its use. Maybe a pair of syscalls like "fdprotect" and "fdunprotect" that take an fd and an integer key. Protected fds would return EBADF or something if accessed. The same integer key must be provided to fdunprotect in order to gain access to it again. Then glibc or valgrind or whatever would just unprotect the fd before operating on it. - DML - 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/
Re: Syslets, Threadlets, generic AIO support, v6
On Wed, 30 May 2007 14:27:52 -0700 (PDT) Linus Torvalds [EMAIL PROTECTED] wrote: Well, don't think of it as a special case at all: think of bit 30 as a the user asked for a non-linear fd. If the sole point is to protect an fd from being closed or operated on outside of a certain context, why not just provide the ability to protect an fd to prevent its use. Maybe a pair of syscalls like fdprotect and fdunprotect that take an fd and an integer key. Protected fds would return EBADF or something if accessed. The same integer key must be provided to fdunprotect in order to gain access to it again. Then glibc or valgrind or whatever would just unprotect the fd before operating on it. - DML - 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/
Re: Detecting process death for anycast named process monitoring
On Wed, 2007-05-02 at 16:30 -0600, Chris Friesen wrote: > Glen Turner wrote: > > > The question is, how can a process with no relationship to another > > process detect that process unexpectedly dying? If named goes > > away to a better place, we want to shut down the interface > > which causes Quagga to inject the anycast route. > We did something similar where arbitrary processes can register to be > sent an arbitrary signal when the state of other processes change. What about something like inotify, but for processes? That would be cool... - DML - 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/
Re: Detecting process death for anycast named process monitoring
On Wed, 2007-05-02 at 16:30 -0600, Chris Friesen wrote: Glen Turner wrote: The question is, how can a process with no relationship to another process detect that process unexpectedly dying? If named goes away to a better place, we want to shut down the interface which causes Quagga to inject the anycast route. We did something similar where arbitrary processes can register to be sent an arbitrary signal when the state of other processes change. What about something like inotify, but for processes? That would be cool... - DML - 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/
Re: sys_write() racy for multi-threaded append?
On Tue, 2007-03-13 at 02:24 +, Alan Cox wrote: > > purports to handle short writes but has never been exercised is > > arguably worse than code that simply bombs on short write. So if I > > can't shim in an induce-short-writes-randomly-on-purpose mechanism > > during development, I don't want short writes in production, period. > > Easy enough to do and gcov plus dejagnu or similar tools will let you > coverage analyse the resulting test set and replay it. You don't even need special tools: just change your code that says: foo = write(fd, mybuf, mycount); to say (for example): foo = write(fd, mybuf, mycount / randomly_either_1_or_2); Why would this need kernel support? The average developer doesn't really need to verify that the *kernel* works. They just need to test their own code paths - and in this case, they can see that foo is less than mycount (sometimes). The code paths don't care that it was not the kernel that caused it. - DML - 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/
Re: sys_write() racy for multi-threaded append?
On Tue, 2007-03-13 at 02:24 +, Alan Cox wrote: purports to handle short writes but has never been exercised is arguably worse than code that simply bombs on short write. So if I can't shim in an induce-short-writes-randomly-on-purpose mechanism during development, I don't want short writes in production, period. Easy enough to do and gcov plus dejagnu or similar tools will let you coverage analyse the resulting test set and replay it. You don't even need special tools: just change your code that says: foo = write(fd, mybuf, mycount); to say (for example): foo = write(fd, mybuf, mycount / randomly_either_1_or_2); Why would this need kernel support? The average developer doesn't really need to verify that the *kernel* works. They just need to test their own code paths - and in this case, they can see that foo is less than mycount (sometimes). The code paths don't care that it was not the kernel that caused it. - DML - 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/
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote: > int signalfd_dequeue(int fd, siginfo_t *info, long timeo); > > The "fd" parameter must ba a signalfd file descriptor. The "info" parameter > is a pointer to the siginfo that will receive the dequeued signal, and > "timeo" is a timeout in milliseconds, or -1 for infinite. > The signalfd_dequeue function returns 0 if successfull. Does this support non-blocking mode? It doesn't seem to at my level of understanding anyway. If I use this with EPOLLET for example, I'd expect to get a single EPOLLIN when a signal arrives, which would indicate to me that I must call signalfd_dequeue() in a loop until I get EAGAIN in order to be sure I've consumed all the outstanding signals so that the edge-triggered notification can be "re-armed". Make sense? - DML - 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/
Re: [patch 2/5] signalfd v2 - signalfd core ...
On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote: int signalfd_dequeue(int fd, siginfo_t *info, long timeo); The fd parameter must ba a signalfd file descriptor. The info parameter is a pointer to the siginfo that will receive the dequeued signal, and timeo is a timeout in milliseconds, or -1 for infinite. The signalfd_dequeue function returns 0 if successfull. Does this support non-blocking mode? It doesn't seem to at my level of understanding anyway. If I use this with EPOLLET for example, I'd expect to get a single EPOLLIN when a signal arrives, which would indicate to me that I must call signalfd_dequeue() in a loop until I get EAGAIN in order to be sure I've consumed all the outstanding signals so that the edge-triggered notification can be re-armed. Make sense? - DML - 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/
Re: [PATCH] remove availability for PAGE_SIZE and friends (i386)
On Tue, 2007-03-06 at 08:31 -0800, David Brown wrote: > +#define __KERNEL__ That's a #define, not an #ifdef... - DML - 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/
Re: [PATCH] remove availability for PAGE_SIZE and friends (i386)
On Tue, 2007-03-06 at 08:31 -0800, David Brown wrote: +#define __KERNEL__ That's a #define, not an #ifdef... - DML - 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/
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote: > Generic event handling mechanism. The patch applied cleanly to 2.6.20 final, but I got a build error: CC kernel/kevent/kevent.o CC kernel/kevent/kevent_user.o CC kernel/kevent/kevent_timer.o CC kernel/kevent/kevent_poll.o make[2]: *** No rule to make target `kernel/kevent/epoll.o', needed by `kernel/kevent/built-in.o'. Stop. make[1]: *** [kernel/kevent] Error 2 make: *** [kernel] Error 2 - DML - 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/
Re: [take35 0/10] kevent: Generic event handling mechanism.
On Thu, 2007-02-01 at 13:12 +0300, Evgeniy Polyakov wrote: Generic event handling mechanism. The patch applied cleanly to 2.6.20 final, but I got a build error: CC kernel/kevent/kevent.o CC kernel/kevent/kevent_user.o CC kernel/kevent/kevent_timer.o CC kernel/kevent/kevent_poll.o make[2]: *** No rule to make target `kernel/kevent/epoll.o', needed by `kernel/kevent/built-in.o'. Stop. make[1]: *** [kernel/kevent] Error 2 make: *** [kernel] Error 2 - DML - 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/
