[PATCH 0/22] Introducing asm/syscalls.h - Kernel

This is a discussion on [PATCH 0/22] Introducing asm/syscalls.h - Kernel ; Hello Alexey, On Mon, 2008-07-21 at 04:28 +0400, Alexey Dobriyan wrote: > On Mon, Jul 21, 2008 at 03:51:40AM +0530, Jaswinder Singh wrote: > > The following series of patches introduce asm/syscalls.h in various > > architectures. > > Copyright ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 28 of 28

Thread: [PATCH 0/22] Introducing asm/syscalls.h

  1. Re: [PATCH 0/22] Introducing asm/syscalls.h

    Hello Alexey,

    On Mon, 2008-07-21 at 04:28 +0400, Alexey Dobriyan wrote:
    > On Mon, Jul 21, 2008 at 03:51:40AM +0530, Jaswinder Singh wrote:
    > > The following series of patches introduce asm/syscalls.h in various
    > > architectures.

    >
    > Copyright for a bunch of prototypes?
    >


    So according to you, there _should_ be no copyright for header files.
    If this is the case, then remove it, I have no objections

    > All those /* kernel/signal.c */ comments are generally stupid and
    > useless, so no point adding even for functions that rarely move
    > (syscalls).
    >
    > Of course, there is no explanation why files are being added.
    >


    It may be useless for you but it looks useful for me.
    If you go though all syscalls patches only then you will figure it out
    syscalls are moving in many files for many architecture.

    There can be many reasons to add syscalls.h, few of them are :-
    1. Declaring syscalls functions before they get used is a nice habit and
    will quite also quiet sparse.

    2. Declaring all arch dependent syscalls under one roof is nice for
    future enhancement for kernel developers as they can see what is defined
    in other architectures and try to follow same prototype as far as
    possible, Then it will be really useful for everyone. And then we can
    move common arch dependent syscalls in one place.

    3. Declaring all arch dependent syscalls under one roof is nice for
    user for reference purpose.

    Thank you,

    Jaswinder Singh.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 0/22] Introducing asm/syscalls.h

    On Mon, Jul 21, 2008 at 11:15:00AM +0530, Jaswinder Singh wrote:
    > It may be useless for you but it looks useful for me.
    > If you go though all syscalls patches only then you will figure it out
    > syscalls are moving in many files for many architecture.
    >
    > There can be many reasons to add syscalls.h, few of them are :-
    > 1. Declaring syscalls functions before they get used is a nice habit and
    > will quite also quiet sparse.
    >
    > 2. Declaring all arch dependent syscalls under one roof is nice for
    > future enhancement for kernel developers as they can see what is defined
    > in other architectures and try to follow same prototype as far as
    > possible, Then it will be really useful for everyone. And then we can
    > move common arch dependent syscalls in one place.
    >
    > 3. ???Declaring all arch dependent syscalls under one roof is nice for
    > user for reference purpose.


    I think it makes more sense to add them to linux/syscall.h, possibly
    with comments mentioning which architectures implement them.

    If there are architectures with different prototypes for the same
    syscall, using an ifdef CONFIG_(arch) is /better/ annotation that having
    them in different header files.

    --
    Intel are signing my paycheques ... these opinions are still mine
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 0/22] Introducing asm/syscalls.h

    Hello Matthew,

    On Sun, 2008-07-20 at 23:55 -0600, Matthew Wilcox wrote:

    > I think it makes more sense to add them to linux/syscall.h, possibly
    > with comments mentioning which architectures implement them.
    >
    > If there are architectures with different prototypes for the same
    > syscall, using an ifdef CONFIG_(arch) is /better/ annotation that having
    > them in different header files.
    >


    linux/syscalls.h is Linux syscall interfaces (non-arch-specific)

    So asm/syscalls.h is Linux syscall interfaces (arch-specific)

    And if we add all arch dependent syscalls.h in linux/syscalls then it
    will be very complex and do not look nice, for example sys_fork is keep
    on changing for many architecture.

    Thank you,

    Jaswinder Singh.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 0/22] Introducing asm/syscalls.h

    On Mon, Jul 21, 2008 at 11:37:14AM +0530, Jaswinder Singh wrote:
    > ???linux/syscalls.h is Linux syscall interfaces (non-arch-specific)
    >
    > So asm/syscalls.h is ???Linux syscall interfaces (arch-specific)


    That's how you see it.

    > And if we add all arch dependent syscalls.h in linux/syscalls then it
    > will be very complex and do not look nice, for example sys_fork is keep
    > on changing for many architecture.


    sys_fork() does seem to be the worst case scenario. I suspect there's
    similar ones (clone?). I still think it's worth adding them all to
    linux/syscalls.h.

    --
    Intel are signing my paycheques ... these opinions are still mine
    "Bill, look, we understand that you're interested in selling us this
    operating system, but compare it to ours. We can't possibly take such
    a retrograde step."
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 0/22] Introducing asm/syscalls.h

    Hello Matthew,

    On Mon, 2008-07-21 at 00:16 -0600, Matthew Wilcox wrote:

    > sys_fork() does seem to be the worst case scenario. I suspect there's
    > similar ones (clone?). I still think it's worth adding them all to
    > linux/syscalls.h.
    >


    I tried my best to make things simpler. I also tried this in :-
    [PATCH 17/22] sh: Introducing asm/syscalls.h
    [PATCH 21/22] x86: Introducing asm/syscalls.h

    For same architecture it looks complex for 32 and 64 bit.

    You can Imagine how linux/syscalls.h will look if we add all
    architectures in it.

    And you can imagine what will be size of linux/syscalls.h. As more than
    60% of arch dependent syscalls have totally different prototypes.

    Thank you,

    Jaswinder Singh.




    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [PATCH 4/22] avr32: Introducing asm/syscalls.h

    Jaswinder Singh wrote:
    > +asmlinkage int sys_fork(struct pt_regs);


    This should be "struct pt_regs *"

    > +asmlinkage int sys_clone(unsigned long, unsigned long,
    > + unsigned long, unsigned long,
    > + struct pt_regs *);
    > +asmlinkage int sys_vfork(struct pt_regs);


    Same thing here.

    Other than that, looks good to me.

    Haavard
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 4/22] avr32: Introducing asm/syscalls.h

    Hello Haavard,

    On Thu, 2008-07-24 at 15:09 +0200, Haavard Skinnemoen wrote:
    > Jaswinder Singh wrote:
    > > +asmlinkage int sys_fork(struct pt_regs);

    >
    > This should be "struct pt_regs *"
    >
    > > +asmlinkage int sys_clone(unsigned long, unsigned long,
    > > + unsigned long, unsigned long,
    > > + struct pt_regs *);
    > > +asmlinkage int sys_vfork(struct pt_regs);

    >
    > Same thing here.
    >
    > Other than that, looks good to me.
    >


    If you want to merge this patch in your tree then let me know.

    I will fix above issues and send updated patch for avr32 tree.

    Thank you,

    Jaswinder Singh.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: [PATCH 4/22] avr32: Introducing asm/syscalls.h

    Jaswinder Singh wrote:
    > If you want to merge this patch in your tree then let me know.


    Well, I'd rather have it go in along with the others through mm or
    something. But if it doesn't depend on anything else, I can take it if
    it makes things easier.

    > I will fix above issues and send updated patch for avr32 tree.


    That'd be great, thanks.

    Haavard
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2