From: Jeff Garzik <jgarzik@mandrakesoft.com>
To: Pavel Machek <pavel@suse.cz>
Cc: torvalds@transmeta.com, kernel list <linux-kernel@vger.kernel.org>
Subject: Re: i386 cleanups
Date: Tue, 17 Apr 2001 18:57:27 -0400 [thread overview]
Message-ID: <3ADCCA57.2A354359@mandrakesoft.com> (raw)
In-Reply-To: <20010417232614.A4377@bug.ucw.cz>
Pavel Machek wrote:
>
> Hi!
>
> These are tiny cleanups you might like. sizes are "logically"
> long. No, it does not matter on i386.
>
> processor.h makes INIT_TSS look much more readable. [Please tell me
> applied or rejected]
>
> Pavel
>
> Index: include/asm-i386/posix_types.h
> ===================================================================
> RCS file: /home/cvs/Repository/linux/include/asm-i386/posix_types.h,v
> retrieving revision 1.1.1.1
> diff -u -u -r1.1.1.1 posix_types.h
> --- include/asm-i386/posix_types.h 2000/09/04 16:50:33 1.1.1.1
> +++ include/asm-i386/posix_types.h 2001/02/13 13:49:18
> @@ -16,9 +16,9 @@
> typedef unsigned short __kernel_ipc_pid_t;
> typedef unsigned short __kernel_uid_t;
> typedef unsigned short __kernel_gid_t;
> -typedef unsigned int __kernel_size_t;
> -typedef int __kernel_ssize_t;
> -typedef int __kernel_ptrdiff_t;
> +typedef unsigned long __kernel_size_t;
> +typedef long __kernel_ssize_t;
> +typedef long __kernel_ptrdiff_t;
If it doesn't matter on i386 why bother?
> #define INIT_TSS { \
> - 0,0, /* back_link, __blh */ \
> - sizeof(init_stack) + (long) &init_stack, /* esp0 */ \
> - __KERNEL_DS, 0, /* ss0 */ \
> - 0,0,0,0,0,0, /* stack1, stack2 */ \
> - 0, /* cr3 */ \
> - 0,0, /* eip,eflags */ \
> - 0,0,0,0, /* eax,ecx,edx,ebx */ \
> - 0,0,0,0, /* esp,ebp,esi,edi */ \
> - 0,0,0,0,0,0, /* es,cs,ss */ \
> - 0,0,0,0,0,0, /* ds,fs,gs */ \
> - __LDT(0),0, /* ldt */ \
> - 0, INVALID_IO_BITMAP_OFFSET, /* tace, bitmap */ \
> - {~0, } /* ioperm */ \
> + esp0: sizeof(init_stack) + (long) &init_stack, \
> + ss0: __KERNEL_DS, \
> + ldt: __LDT(0), \
> + bitmap: INVALID_IO_BITMAP_OFFSET, \
> + ioperm: {~0, } \
IIRC certain key structures cannot be taken to gcc's style of struct
initialization, and IIRC this is one of them. Maybe that's a egcs-1.1.2
bug. Have you looked at the assembly output to make sure things are
100% ok after this change?
Regards,
Jeff, who wonders if there is a way to upgrade human memory as easily as
computer memory...
--
Jeff Garzik | "Give a man a fish, and he eats for a day. Teach a
Building 1024 | man to fish, and a US Navy submarine will make sure
MandrakeSoft | he's never hungry again." -- Chris Neufeld
next prev parent reply other threads:[~2001-04-17 22:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-17 21:26 i386 cleanups Pavel Machek
2001-04-17 21:46 ` Linus Torvalds
2001-04-18 22:02 ` Michael Meissner
2001-04-17 22:57 ` Jeff Garzik [this message]
2001-04-18 9:10 ` Abramo Bagnara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ADCCA57.2A354359@mandrakesoft.com \
--to=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox