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.
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, whe
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 v
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
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
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 the
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 a
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 E
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 reall
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
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)
>
Hi,
On Tue, 9 Aug 2005, Hugh Dickins wrote:
> PageReserved is about those pages which are managed by PageReserved.
> But quite what it means is unclear, one of the reasons to eliminate it.
> (Why is kernel text PageReserved?)
Short answer: /dev/mem
(Amazing that nobody mentioned it so far...)
T
Hi,
On Wed, 10 Aug 2005, Christoph Hellwig wrote:
> The sys_ptrace boilerplate code (everything outside the big switch
> statement for the arch-specific requests) is shared by most
> architectures. This patch moves it to kernel/ptrace.c and leaves the
> arch-specific code as arch_ptrace.
No obj
Hi,
On Wed, 10 Aug 2005, john stultz wrote:
> Here's the next rev in my rework of the current timekeeping subsystem.
> No major changes, only some cleanups and further splitting the larger
> patches into smaller ones.
>
> The goal of this patch set is to provide a simplified and streamline
Hi,
On Wed, 10 Aug 2005, john stultz wrote:
> The goal of this patch set is to isolate the in kernel NTP state
> machine in the hope of simplifying the current timekeeping code and
> allowing for optional future changes in the timekeeping subsystem.
>
> I've tried to address some of the co
Hi,
On Mon, 15 Aug 2005, john stultz wrote:
> > I think most of this is premature cleanup. As it also changes the logic in
> > small ways, I'm not even sure it qualifies as a cleanup.
>
> Please, Roman, I'm spending quite a bit of time breaking this up into
> small chunks specifically to help t
Hi,
On Mon, 15 Aug 2005, john stultz wrote:
> > Please provide the right abstractions, e.g. leave the gettimeofday
> > implementation to the timesource and use some helper (template) functions
> > to do the actual work. Basically as long as you have a cycle_t in the
> > common code something i
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 lis
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
> 03
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 con
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 Ncurs
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 requi
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?
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 t
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&R.
So it basically comes down to p
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
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 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
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 impro
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_ diff
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 ra
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 sh
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,
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
> > t
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 th
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 comme
Hi,
On Tue, 16 Aug 2005, john stultz wrote:
> If they are private clock variables, why are they in the generic
> timer.c? Everyone is using it in exactly the same way, no? Why do you
> oppose having the adjustment and phase values behind an ntp_function()
> interface?
These values belong to the
Hi,
On Fri, 19 Aug 2005, john stultz wrote:
> timekeeping_perioidic_hook():
>
> /* get ntp adjusted interval length*/
> interval_length = get_timesource_interval(ppm)
Here starts the problem, this requires more expensive math than necessary,
as every time you first have to scale th
Hi,
On Mon, 22 Aug 2005, Chris Wright wrote:
> * Adrian Bunk ([EMAIL PROTECTED]) wrote:
> > config SECURITY
> > bool "Enable different security models"
> > + depends on SYSFS
>
> Hmm, what about select instead?
What's wrong with a normal dependency?
Please don't abuse select, use it only
Hi,
On Mon, 22 Aug 2005, Andrew Morton wrote:
> Al Viro <[EMAIL PROTECTED]> wrote:
> >
> > mail -s '[PATCH] (45/46) %t... in vsnprintf' [EMAIL PROTECTED] <<'EOF'
>
>
>
> Could you copy a mailing list on patches, please?
Seconded.
Al, I'd like to know which of the m68k related patches you want
Hi,
On Tue, 23 Aug 2005, Al Viro wrote:
> As for your s/thread_info/stack/ - I don't believe it's doable in mainline
> right now. It's definitely separate from m68k merge and should not be
> mixed into it. Moreover, mandatory changes to every platform arch-specific
> code over basically cosmeti
Hi,
On Mon, 22 Aug 2005, john stultz wrote:
> The reason why we calculate the interval_length in the continuous
> timesource case is because we are not assuming anything about the
> frequency that the timekeeping_periodic_hook() is called.
The problem with your patch is that it doesn't allow mak
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
> I'm assuming gettimeofday()/clock_gettime() looks something like:
>xtime + (get_cycles()-last_update)*(mult+ntp_adj)>>shift
Where did you get the ntp_adj from? It's not in my example.
gettimeofday() was in the previous mail: "xtime + (cycle_offse
Hi,
On Tue, 23 Aug 2005, john stultz wrote:
> In the case above, you're accumulating in fixed cycle intervals. This
> does avoid having to do the mult/shift combo each interrupt, however
> since you do not accumulate the entire interval, and there is some
> sub-tick remainder in cycle_offset. We
Hi,
On Wed, 24 Aug 2005, Ulrich Windl wrote:
> I'm having a problem with your wording: NTP _does_ control the "system time"
> (system clock), because it's the only clock it can use. The "reference time"
> is
> usually remote or elsewhere (multiple sources). Local NTP does not control
> the
>
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> Ok, so then to clarify the above (as you mention gettimeofday uses
> system_time), would your gettimeofday look something like:
>
> gettiemofday():
> return (system_time + (cycle_offset * mult) + error)>> shift
>
> ?
No.
reference_ti
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> from your example:
> > // at init: system_update = update_cycles * mult;
> > system_time += system_update;
>
> and:
> > error = system_time - (xtime.tv_nsec << shift);
>
> This doesn't seem to make sense with the above.
Hi,
On Wed, 24 Aug 2005, john stultz wrote:
> Ok, well, I'm still at a loss for understanding how this avoids my
> concern about time inconsistencies.
Let's take a simple example to demonstrate the difference between system
time and reference time.
NTP tells us to update the reference time by 1
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> diff -urN RC13-rc7/sound/oss/dmasound/dmasound_paula.c
> RC13-rc7-dmasound-lvalues/sound/oss/dmasound/dmasound_paula.c
> --- RC13-rc7/sound/oss/dmasound/dmasound_paula.c 2005-06-17
> 15:48:29.0 -0400
> +++ RC13-rc7-dmasound-lvalues/sound/os
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
>
> diff -urN RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h
> RC13-rc7-amigaints/include/asm-m68k/amigaints.h
> --- RC13-rc7-sun3_pgtable/include/asm-m68k/amigaints.h2005-06-17
> 15:48:29.0 -0400
> +++ RC13-rc7-amigaints/include/
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
>
> +static inline void setup_thread_info(struct task_struct *p, struct
> thread_info *ti)
> +{
> + *ti = *p->thread_info;
> +}
> +
>
> - *ti = *orig->thread_info;
> *tsk = *orig;
> + setup_thread_info(tsk, ti);
> tsk->thread_in
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> > > > >
> > > > > - *ti = *orig->thread_info;
> > > > > *tsk = *orig;
> > > > > + setup_thread_info(tsk, ti);
> > > > > tsk->thread_info = ti;
> > > > > ti->task = tsk;
> > > >
> > > > This introduces a subtle ordering require
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 11:15:24AM +0200, Roman Zippel wrote:
> > >
> > > - *ti = *orig->thread_info;
> > > *tsk = *orig;
> > > + setup_thread_info(tsk, ti);
> > > tsk->thread_info = ti;
>
:Maintained
M68K ARCHITECTURE
P: Geert Uytterhoeven
M: [EMAIL PROTECTED]
-P: Roman Zippel
-M: [EMAIL PROTECTED]
+P: Al Viro
+M: [EMAIL PROTECTED]
L: [EMAIL PROTECTED]
W: http://www.linux-m68k.org/
W: http://linux-m68k-cvs.ubb.ca/
I'm seriou
Hi,
On Thu, 25 Aug 2005, Al Viro wrote:
> OK, fuck that. Consider the patchbomb withdrawn.
Thanks.
Nobody is going to die that m68k doesn't compile again for another
release. I appreciate the kick to get it going, but there is no point in
forcing it a few days before the release, which basica
Hi,
On Tue, 30 Aug 2005, Knut Petersen wrote:
> > Probably you can make it even faster by avoiding the multiplication, like
> >
> >unsigned int offset = 0;
> >for (i = 0; i < image.height; i++) {
> > dst[offset] = src[i];
> > offset += pitch;
> >}
> >
>
> More than two deca
Hi,
On Wed, 31 Aug 2005, Knut Petersen wrote:
> How could I make it an inline function? It is used in console/bitblit.c,
> nvidia/nvidia.c,
> riva/fbdev.c and softcursor.c.
Something like below, which has the advantange that there is still only
one implementation of the function and if it's sti
Hi,
On Wed, 31 Aug 2005, Antonino A. Daplas wrote:
> Roman, okay if you have a 'Signed-off-by' line?
Okay.
bye, Roman
-
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-
Hi,
On Wed, 31 Aug 2005, Knut Petersen wrote:
> +static inline void __fb_pad_aligned_buffer(u8 *dst, u32 d_pitch, u8 *src, +
> u32 s_pitch, u32 height)
> +{
> + int i, j;
> +
> + if (likely(s_pitch==1))
> + for(i=0; i < height; i++)
> + dst[d_pitch*i] = src
Hi,
On Wed, 31 Aug 2005, Knut Petersen wrote:
> I added the multiply back because gcc (v. 3.3.4) does generate the fastest
> code
> if I write it this way.
The multiply is not generally faster, so your version may be the fastest,
but in other situations it will be a lot slower. My version is ge
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> + flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
> + clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
> +
> + result = -EINVAL;
> + if (flags & ~TIMEOUT_RELATIVE)
> + goto out;
> +
> + /* someday, we should support *all*
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> >Why is that needed in a _general_ timeout API? What exactly makes it so
> >useful for everyone and not just more complex for everyone?
>
> Because if a system call gets a timeout specification it needs to
> verify its correctness first. In
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> I cannot produce (top of my head) any other POSIX API calls that
> allow you to specify another clock source, but they are there,
> somewhere. If I am to introduce a new API, I better make it
> flexible enough so that other subsystems can u
Hi,
On Wed, 31 Aug 2005, Perez-Gonzalez, Inaky wrote:
> Hmm, I cannot think of more ways to specify a timeout than how
> long I want to wait (relative) or until when (absolute) and which
> is the reference clock. And they don't seem broken to me, common
> sense, in any case. Do you have any examp
Hi,
On Wed, 31 Aug 2005, Daniel Walker wrote:
> > What "more versions" are you talking about? When you convert a user time
> > to kernel time you can automatically validate it and later you can use
> > standard kernel APIs, so you don't have to add even more API bloat.
>
> What's kernel time?
Hi,
On Thu, 1 Sep 2005, Perez-Gonzalez, Inaky wrote:
> >You still didn't explain what's the point in choosing different clock
> >sources for a _timeout_.
>
> The same reasons that compel to have CLOCK_REALTIME or
> CLOCK_MONOTONIC, for example. Or the need to time out on a
> high resolution clo
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> > When you convert a user time to kernel time you can
> > automatically validate
>
> Kernel time sucks. It is just a single clock, it may not have
> the attributes of the clock that the user really wished to use.
Wrong. The kernel time is simple and e
Hi,
On Thu, 1 Sep 2005, Joe Korty wrote:
> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>
> > You still didn't explain what's the point in choosing
> > different clock sources for a _timeout_.
>
> Well, if CLOCK_REALTIME is set forward by a mi
- create helper function singlestep_disable()
- move variable definitions to the top of the function
- use "out_eio" label as common error destination
- don't clear failure value for PTRACE_SETREGS/PTRACE_GETREGS
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch
Move a few cache functions into its own file and fix flush_icache_range()
so it can handle both kernel and user addresses correctly (assuming
context is set correctly).
Turn copy_to_user_page/copy_from_user_page into inline functions and add a
missing cache flush.
Signed-off-by: Roman Zippel
This reformats and properly indents sys_ptrace
(only whitespace changes).
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/m68k/kernel/ptrace.c | 337 ++
1 files changed, 168 insertions(+), 169 deletions(-)
Index: linux-2.6/arc
Use the builtin functions for memset/memclr/memcpy, special optimizations
for page operations have dedicated functions now. Uninline memmove/memchr
and move all functions into a single file and clean it up a little.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/m68k/
Hi,
This patch series brings the m68k closer to a working state. It consists
of two basic parts, the first five patches do the minimal changes to get
m68k compiling in mainline, the last five patches do a cleanup of the
kernel API.
The patches are against -mm, but the only conflict for the sec
ff-by: Roman Zippel <[EMAIL PROTECTED]>
---
include/asm-m68k/thread_info.h |4 ++--
include/linux/init_task.h |1 +
include/linux/sched.h |5 +++--
kernel/fork.c |1 +
4 files changed, 7 insertions(+), 4 deletions(-)
Index: linux-2.6-mm/in
ointer immediately past the end of
thread_info.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
include/linux/sched.h | 11 +++
kernel/fork.c |3 +--
kernel/sched.c|4 ++--
3 files changed, 14 insertio
IL PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
include/linux/sched.h | 16 +---
kernel/exit.c |2 +-
kernel/fork.c |4 ++--
kernel/sched.c|6 +++---
4 files changed, 15 insertions(+), 13 deletions(-)
Index: linux-2.6-mm/
l Viro <[EMAIL PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/m68k/kernel/asm-offsets.c |5 +
include/asm-m68k/processor.h |2 ++
include/asm-m68k/thread_info.h | 14 ++
3 files changed, 17 insertions(+), 4 deletions(-)
Index: linux-2.6-m
current_thread_info() usage, which requires on m68k a structure
(task_struct) not yet defined at this point.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/m68k/fpsp040/skeleton.S |6 +--
arch/m68k/ifpsp060/iskeleton.S |6 +--
arch/m68k/kernel/asm-offsets.c |5 --
arch/m68k/kernel/e
Convert expression of the form (p->thread_info + 1) to use end_of_stack(),
which makes it also more readable.
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/arm/kernel/process.c |2 +-
arch/arm/kernel/traps.c |4 ++--
arch/arm26/kernel/traps.c |4 ++--
arch/p
PROTECTED]>
Signed-off-by: Roman Zippel <[EMAIL PROTECTED]>
---
arch/sparc/lib/bitext.c |1 +
include/linux/hardirq.h |2 ++
include/linux/interrupt.h |1 +
include/linux/preempt.h |1 +
include/linux/sched.h |4
include/linux/smp_lock.h |3 +--
6
This changes direct access to the thread_info field to use the stack field
instead, whereever it's obvious it actually wants the stack field (all of
them are also cast to a different type).
Also included are the offsetof() users to use the stack field.
Signed-off-by: Roman Zippel &l
Hi,
On Thu, 1 Sep 2005, Andrew Morton wrote:
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > Can I assume that the five m68k patches can be split apart from the five
> > patches which dink with task_struct? ie: if the task_struct patches go in
> > later, does anything bad happen?
>
> eh, for
Hi,
On Tue, 6 Sep 2005 [EMAIL PROTECTED] wrote:
> Sanitized and fixed floppy dependencies: split the messy dependencies for
> BLK_DEV_FD by introducing a new symbol (ARCH_MAY_HAVE_PC_FDC), making
> BLK_DEV_FD depend on that one and taking declarations of ARCH_MAY_HAVE_PC_FDC
> to arch/*/Kconfig.
Hi,
On Tue, 6 Sep 2005 [EMAIL PROTECTED] wrote:
> We could go for your "allow" form, but what else would need it? USB gadget
> stuff with its "must have at most one low-level driver, high-level drivers
> should be allowed only if a low-level one is present"? RTC mess is better
> solved in other
Hi,
On Tue, 6 Sep 2005 [EMAIL PROTECTED] wrote:
> # there's a glue for PC-like FDC
> allow BLD_DEV_FD
>
> If you insist on having dummy config around allow/select, I don't see any
> real benefits in using "allow" form...
It has to be in some context, otherwise Kconfig can't tell whether it
bel
Hi,
On Fri, 9 Sep 2005, Brown, Len wrote:
> >--- drivers/acpi/Kconfig.orig2005-09-09 09:46:26.0 +0200
> >+++ drivers/acpi/Kconfig 2005-09-09 09:46:46.0 +0200
> >@@ -197,7 +197,7 @@ config ACPI_ASUS
> > config ACPI_IBM
> > tristate "IBM ThinkPad Laptop Extras"
> >
Hi,
On Fri, 9 Sep 2005 [EMAIL PROTECTED] wrote:
> Sigh... It should be left as #if, of course, but I suspect that cleaner way
> to
> deal with that would be (in Kconfig)
>
> config ACPI_BLACKLIST_YEAR
> int "Disable ACPI for systems before Jan 1st this year" if X86
> default 0
Hi,
On Fri, 9 Sep 2005, john stultz wrote:
> +/* Required to safely shift negative values */
> +#define shiftR(x, s) ({ __typeof__(x) __x = x;\
> + __typeof__(s) __s = s; \
> + (__x < 0) ? (-((-__x) >> (__s))) : ((__x) >> (__s));})
> +
Some parenthesis are missing and som
Hi,
On Thursday 3. January 2008, Ph. Marek wrote:
> So I took a look at "Help", and saw that blob:
>
> Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
> NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK
> || NETFILTER_XT_MATCH_CONNMARK && NET &&
Hi,
On Wednesday 2. January 2008, Eric Sandeen wrote:
> Roman, with this on top does it look better to you?
Looks good, thanks.
> I'll get hfsplus done in a bit.
I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much
identical.
bye, Roman
--
To unsubscribe from this list:
Hi,
On Wed, 16 Jan 2008, Sam Ravnborg wrote:
> But one feature I really would like to see is named chocies so we can do
> stuff like:
>
> choice X86_PROCESSOR
>
> config GENERIC_PROCESSOR
> bool "A generic X86 processor"
> endchoice
>
>
> ...
>
> choice PPC_PROCESSOR
>
> config GENER
Hi,
On Wed, 16 Jan 2008, Jan Beulich wrote:
> now that I finally found time to look into the problems that caused the
> patch changing boolean/tristate choice behavior to be reverted I find
> that due to the way things worked in the past there are a couple of
> cases where config options not real
Hi,
On Thu, 20 Sep 2007, Shlomi Fish wrote:
> Which specific problems do you see with the coding style of the patch? Can
> you
> comment on it?
Mostly whitespace around any braces, please keep it close to the other
source.
> > I would also prefer to move more of the search functionality into
Hi,
On Mon, 1 Oct 2007, Oleg Verych wrote:
> Today's kconfig was proposed and accepted in a very unpleasant
> circumstances, has very poor design, development and no working
> alternative (for 5+ years now).
If you want to make such statements, you have to offer a little more than
the hot air y
Hi,
On Thursday 20 December 2007, Eric Sandeen wrote:
> Index: linux-2.6.24-rc3/fs/hfs/brec.c
> ===
> --- linux-2.6.24-rc3.orig/fs/hfs/brec.c
> +++ linux-2.6.24-rc3/fs/hfs/brec.c
> @@ -44,10 +44,21 @@ u16 hfs_brec_keylen(struct hfs_b
Hi,
On Monday 17 December 2007, H. Peter Anvin wrote:
> kernel/timeconst.pl | 340
I agree with Jan that it would be better to put this into scripts.
In the long term we could also detect some of the simple special cases, so we
can finally inline some of these functions again, this w
Hi,
On Wed, 28 Nov 2007, Paul Mundt wrote:
> Adrian mentioned a few weeks ago that KCONFIG_ALLCONFIG is the way to
> go to ensure that things like allyes/allmod/allnoconfig work with a
> constrained set of symbols, with the implication that this holds
> true for randconfig as well.
BTW another p
101 - 200 of 538 matches
Mail list logo
