From owner-freebsd-arch@FreeBSD.ORG Tue May 3 15:53:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDD7A16A4CE for ; Tue, 3 May 2005 15:53:34 +0000 (GMT) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 657FE43D49 for ; Tue, 3 May 2005 15:53:34 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from h00609772adf0.ne.client2.attbi.com ([66.30.114.143]) by comcast.net (sccrmhc14) with ESMTP id <20050503155328014009ohrqe>; Tue, 3 May 2005 15:53:29 +0000 Received: from h00609772adf0.ne.client2.attbi.com (localhost.127.in-addr.arpa [127.0.0.1])j43FrmOs003864 for ; Tue, 3 May 2005 11:53:48 -0400 (EDT) (envelope-from rodrigc@h00609772adf0.ne.client2.attbi.com) Received: (from rodrigc@localhost)j43FrmNM003863 for freebsd-arch@freebsd.org; Tue, 3 May 2005 11:53:48 -0400 (EDT) (envelope-from rodrigc) Date: Tue, 3 May 2005 11:53:47 -0400 From: Craig Rodrigues To: freebsd-arch@freebsd.org Message-ID: <20050503155347.GA3768@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: Aligning extended attributes API with Mac OSX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 15:53:34 -0000 Hi, An extended attributes API was just added to Mac OSX 10.4. This API looks very similar to FreeBSD's. Right now there is no POSIX standard for extended attributes, but EA are useful for many different types of things. I don't know if EA are widely used in applications on FreeBSD, but what do people think about aligning our API with Mac OSX? Here are the man pages for some of the API's: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/listxattr.2.html http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setxattr.2.html http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/removexattr.2.html#//apple_ref/doc/man/2/removexattr http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getxattr.2.html#//apple_ref/doc/man/2/getxattr The FreeBSD equivalents are documented in extattr(2). -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-arch@FreeBSD.ORG Tue May 3 16:48:08 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E86C16A4CE for ; Tue, 3 May 2005 16:48:08 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC9C843D76 for ; Tue, 3 May 2005 16:48:07 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.21] (rat.samsco.home [192.168.254.21]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j43GpDBm056647; Tue, 3 May 2005 10:51:13 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4277AAE7.8070006@samsco.org> Date: Tue, 03 May 2005 10:46:31 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.5) Gecko/20050321 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20050503155347.GA3768@crodrigues.org> In-Reply-To: <20050503155347.GA3768@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.2 required=3.8 tests=ALL_TRUSTED,REMOVE_PAGE autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: freebsd-arch@freebsd.org Subject: Re: Aligning extended attributes API with Mac OSX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 16:48:08 -0000 Craig Rodrigues wrote: > Hi, > > An extended attributes API was just added to Mac OSX 10.4. > This API looks very similar to FreeBSD's. > Right now there is no POSIX standard for extended attributes, > but EA are useful for many different types of things. > > I don't know if EA are widely used in applications on FreeBSD, > but what do people think about aligning our API with > Mac OSX? > > Here are the man pages for some of the API's: > > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/listxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/removexattr.2.html#//apple_ref/doc/man/2/removexattr > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getxattr.2.html#//apple_ref/doc/man/2/getxattr > > > The FreeBSD equivalents are documented in extattr(2). > Evaluating the OSX model and aligning with it is something that is going to be looked at in the coming months for sure. Scott From owner-freebsd-arch@FreeBSD.ORG Tue May 3 18:44:45 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B36016A4CE; Tue, 3 May 2005 18:44:45 +0000 (GMT) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9129E43D54; Tue, 3 May 2005 18:44:41 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)j43IiK7v073557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 May 2005 03:44:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 04 May 2005 03:44:20 +0900 Message-ID: From: Hajimu UMEMOTO To: arch@FreeBSD.org, standards@FreeBSD.org, current@FreeBSD.org User-Agent: Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Wed, 04 May 2005 03:44:21 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on cheer.mahoroba.org Subject: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 18:44:45 -0000 Hi, The ai_addrlen of a struct addrinfo used to be a size_t, per RFC 2553. In XNS5.2, and subsequently in POSIX-2001 and RFC 3493, it was changed to a socklen_t. And, the n_net of a struct netent used to be an unsigned long integer. In XNS5, and subsequently in POSIX-2001, it was changed to an uint32_t. I made a patch to correct these: http://www.imasy.or.jp/~ume/FreeBSD/netdb.h-padding.diff To accomodate for this while preserving ABI compatibility with the old interface, we need to prepend or append 32 bits of padding, depending on the (LP64) architecture's endianness. I wish to delete these padding before 6.0-RELEASE. Please review it. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-arch@FreeBSD.ORG Tue May 3 19:00:24 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 209B416A4D6 for ; Tue, 3 May 2005 19:00:24 +0000 (GMT) Received: from delight.idiom.com (delight.idiom.com [216.240.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2921043D94 for ; Tue, 3 May 2005 19:00:12 +0000 (GMT) (envelope-from julian@elischer.org) Received: from idiom.com (idiom.com [216.240.32.1]) by delight.idiom.com (Postfix) with ESMTP id C55B51EFB50; Tue, 3 May 2005 12:00:07 -0700 (PDT) Received: from [192.168.2.3] (home.elischer.org [216.240.48.38]) by idiom.com (8.12.11/8.12.11) with ESMTP id j43J05HW041622; Tue, 3 May 2005 12:00:07 -0700 (PDT) (envelope-from julian@elischer.org) Message-ID: <4277CA33.3060706@elischer.org> Date: Tue, 03 May 2005 12:00:03 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050424 X-Accept-Language: en, hu MIME-Version: 1.0 To: Craig Rodrigues References: <20050503155347.GA3768@crodrigues.org> In-Reply-To: <20050503155347.GA3768@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-arch@freebsd.org Subject: Re: Aligning extended attributes API with Mac OSX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 19:00:24 -0000 Craig Rodrigues wrote: > Hi, > > An extended attributes API was just added to Mac OSX 10.4. > This API looks very similar to FreeBSD's. though one is ascii and the other is UTF8 and one is name:value and the other is name=value > Right now there is no POSIX standard for extended attributes, > but EA are useful for many different types of things. > > I don't know if EA are widely used in applications on FreeBSD, > but what do people think about aligning our API with > Mac OSX? > > Here are the man pages for some of the API's: > > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/listxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/removexattr.2.html#//apple_ref/doc/man/2/removexattr > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getxattr.2.html#//apple_ref/doc/man/2/getxattr > > > The FreeBSD equivalents are documented in extattr(2). > From owner-freebsd-arch@FreeBSD.ORG Tue May 3 22:47:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B099116A4CE; Tue, 3 May 2005 22:47:26 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E28E43D5D; Tue, 3 May 2005 22:47:26 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.3/8.13.1) with ESMTP id j43Mi9A3016397; Tue, 3 May 2005 18:44:09 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.3/8.13.1/Submit) id j43Mi99l016396; Tue, 3 May 2005 18:44:09 -0400 (EDT) (envelope-from das@FreeBSD.ORG) Date: Tue, 3 May 2005 18:44:09 -0400 From: David Schultz To: Hajimu UMEMOTO Message-ID: <20050503224409.GA16252@VARK.MIT.EDU> Mail-Followup-To: Hajimu UMEMOTO , arch@FreeBSD.ORG, standards@FreeBSD.ORG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: cc: arch@FreeBSD.ORG cc: standards@FreeBSD.ORG Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2005 22:47:26 -0000 On Wed, May 04, 2005, Hajimu UMEMOTO wrote: > Hi, > > The ai_addrlen of a struct addrinfo used to be a size_t, per RFC 2553. > In XNS5.2, and subsequently in POSIX-2001 and RFC 3493, it was changed > to a socklen_t. > And, the n_net of a struct netent used to be an unsigned long integer. > In XNS5, and subsequently in POSIX-2001, it was changed to an > uint32_t. > > I made a patch to correct these: > > http://www.imasy.or.jp/~ume/FreeBSD/netdb.h-padding.diff > > To accomodate for this while preserving ABI compatibility with the old > interface, we need to prepend or append 32 bits of padding, depending > on the (LP64) architecture's endianness. I wish to delete these > padding before 6.0-RELEASE. > > Please review it. I have a subset of this (along with some other changes for POSIX) in my tree---see the patch below. My patch only includes the part that can be done without breaking the ABI. (Actually, doesn't your patch *fix* the ABI with respect to FreeBSD 4.X? It just breaks it w.r.t. 5.X, I think.) Assuming that people are willing to accept the ABI breakage (and I'm not sure this is true), the patch looks reasonable. I have two minor comments: - You should use socklen_t instead of uint32_t, as appropriate. - It's probably better to use the machine/endian.h macros to test endianness instead of hard-coding every architecture. Index: netdb.h =================================================================== RCS file: /cvs/src/include/netdb.h,v retrieving revision 1.34 diff -u -r1.34 netdb.h --- netdb.h 14 Feb 2005 11:33:11 -0000 1.34 +++ netdb.h 21 Mar 2005 00:57:54 -0000 @@ -63,17 +63,19 @@ #include #include - -#ifndef _SIZE_T_DECLARED -typedef __size_t size_t; -#define _SIZE_T_DECLARED -#endif +#include +#include #ifndef _SOCKLEN_T_DECLARED typedef __socklen_t socklen_t; #define _SOCKLEN_T_DECLARED #endif +#ifndef _UINT32_T_DECLARED +typedef __uint32_t uint32_t; +#define _UINT32_T_DECLARED +#endif + #ifndef _PATH_HEQUIV # define _PATH_HEQUIV "/etc/hosts.equiv" #endif @@ -100,13 +102,19 @@ /* * Assumption here is that a network number - * fits in an unsigned long -- probably a poor one. + * fits in 32 bits -- probably a poor one, but required by POSIX. */ struct netent { char *n_name; /* official name of net */ char **n_aliases; /* alias list */ int n_addrtype; /* net address type */ - unsigned long n_net; /* network # */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN + uint32_t __unused; /* ABI compat */ +#endif + uint32_t n_net; /* network # */ +#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN + uint32_t __unused; /* ABI compat */ +#endif }; struct servent { @@ -127,24 +135,32 @@ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ - size_t ai_addrlen; /* length of ai_addr */ + /* XXX ai_addrlen should have type socklen_t */ + __size_t ai_addrlen; /* length of ai_addr */ char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ }; +/* Highest reserved port number. Keep in sync with netinet/in.h. */ +#define IPPORT_RESERVED 1024 + /* * Error return codes from gethostbyname() and gethostbyaddr() * (left in h_errno). */ +#if __BSD_VISIBLE #define NETDB_INTERNAL -1 /* see errno */ #define NETDB_SUCCESS 0 /* no problem */ +#endif #define HOST_NOT_FOUND 1 /* Authoritative Answer Host not found */ #define TRY_AGAIN 2 /* Non-Authoritative Host not found, or SERVERFAIL */ #define NO_RECOVERY 3 /* Non recoverable errors, FORMERR, REFUSED, NOTIMP */ #define NO_DATA 4 /* Valid name, no data record of requested type */ +#if __BSD_VISIBLE #define NO_ADDRESS NO_DATA /* no address, look for MX record */ +#endif /* * Error return codes from getaddrinfo() @@ -166,9 +182,14 @@ #define EAI_SERVICE 9 /* servname not supported for ai_socktype */ #define EAI_SOCKTYPE 10 /* ai_socktype not supported */ #define EAI_SYSTEM 11 /* system error returned in errno */ +#if __BSD_VISIBLE #define EAI_BADHINTS 12 #define EAI_PROTOCOL 13 -#define EAI_MAX 14 +#endif +#define EAI_OVERFLOW 14 /* argument buffer overflowed */ +#if __BSD_VISIBLE +#define EAI_MAX 15 +#endif /* * Flag values for getaddrinfo() @@ -177,23 +198,33 @@ #define AI_CANONNAME 0x00000002 /* fill ai_canonname */ #define AI_NUMERICHOST 0x00000004 /* prevent host name resolution */ #define AI_NUMERICSERV 0x00000008 /* prevent service name resolution */ + +#if __BSD_VISIBLE /* valid flags for addrinfo (not a standard def, apps should not use it) */ #define AI_MASK \ (AI_PASSIVE | AI_CANONNAME | AI_NUMERICHOST | AI_NUMERICSERV | \ AI_ADDRCONFIG) +#endif #define AI_ALL 0x00000100 /* IPv6 and IPv4-mapped (with AI_V4MAPPED) */ +#if __BSD_VISIBLE #define AI_V4MAPPED_CFG 0x00000200 /* accept IPv4-mapped if kernel supports */ +#endif #define AI_ADDRCONFIG 0x00000400 /* only if any address is assigned */ #define AI_V4MAPPED 0x00000800 /* accept IPv4-mapped IPv6 address */ + +#if __BSD_VISIBLE /* special recommended flags for getipnodebyname */ #define AI_DEFAULT (AI_V4MAPPED_CFG | AI_ADDRCONFIG) +#endif +#if __BSD_VISIBLE /* * Constants for getnameinfo() */ #define NI_MAXHOST 1025 #define NI_MAXSERV 32 +#endif /* * Flag values for getnameinfo() @@ -203,72 +234,81 @@ #define NI_NAMEREQD 0x00000004 #define NI_NUMERICSERV 0x00000008 #define NI_DGRAM 0x00000010 -#if 1 /* obsolete */ +#if __BSD_VISIBLE /* obsolete */ #define NI_WITHSCOPEID 0x00000020 #endif +#if __BSD_VISIBLE /* * Scope delimit character */ #define SCOPE_DELIMITER '%' +#endif __BEGIN_DECLS void endhostent(void); void endnetent(void); -void endnetgrent(void); void endprotoent(void); void endservent(void); -void freehostent(struct hostent *); -struct hostent *gethostbyaddr(const char *, int, int); +struct hostent *gethostbyaddr(const void *, int, int); struct hostent *gethostbyname(const char *); -struct hostent *gethostbyname2(const char *, int); struct hostent *gethostent(void); -struct hostent *getipnodebyaddr(const void *, size_t, int, int *); -struct hostent *getipnodebyname(const char *, int, int, int *); struct netent *getnetbyaddr(unsigned long, int); struct netent *getnetbyname(const char *); struct netent *getnetent(void); -int getnetgrent(char **, char **, char **); struct protoent *getprotobyname(const char *); struct protoent *getprotobynumber(int); struct protoent *getprotoent(void); struct servent *getservbyname(const char *, const char *); struct servent *getservbyport(int, const char *); struct servent *getservent(void); -void herror(const char *); -__const char *hstrerror(int); -int innetgr(const char *, const char *, const char *, const char *); + +/* XXX Should replace __size_t with socklen_t below */ void sethostent(int); /* void sethostfile(const char *); */ void setnetent(int); void setprotoent(int); -int getaddrinfo(const char *, const char *, - const struct addrinfo *, struct addrinfo **); -int getnameinfo(const struct sockaddr *, socklen_t, char *, - size_t, char *, size_t, int); +int getaddrinfo(const char * __restrict, const char * __restrict, + const struct addrinfo * __restrict, + struct addrinfo ** __restrict); +int getnameinfo(const struct sockaddr * __restrict, socklen_t, + char * __restrict, __size_t, char * __restrict, + __size_t, int); void freeaddrinfo(struct addrinfo *); const char *gai_strerror(int); -void setnetgrent(const char *); void setservent(int); +#if __BSD_VISIBLE +void endnetgrent(void); +void freehostent(struct hostent *); +struct hostent *gethostbyname2(const char *, int); +struct hostent *getipnodebyaddr(const void *, __size_t, int, int *); +struct hostent *getipnodebyname(const char *, int, int, int *); +int getnetgrent(char **, char **, char **); +void herror(const char *); +__const char *hstrerror(int); +int innetgr(const char *, const char *, const char *, const char *); +void setnetgrent(const char *); +#endif + /* * PRIVATE functions specific to the FreeBSD implementation */ /* DO NOT USE THESE, THEY ARE SUBJECT TO CHANGE AND ARE NOT PORTABLE!!! */ int * __h_error(void); -void _sethosthtent(int); -void _endhosthtent(void); -void _sethostdnsent(int); -void _endhostdnsent(void); -void _setnethtent(int); -void _endnethtent(void); -void _setnetdnsent(int); -void _endnetdnsent(void); -struct hostent * _gethostbynisname(const char *, int); -struct hostent * _gethostbynisaddr(const char *, int, int); -void _map_v4v6_address(const char *, char *); -void _map_v4v6_hostent(struct hostent *, char **, char **); +void __sethosthtent(int); +void __endhosthtent(void); +void __sethostdnsent(int); +void __endhostdnsent(void); +void __setnethtent(int); +void __endnethtent(void); +void __setnetdnsent(int); +void __endnetdnsent(void); +struct hostent * __gethostbynisname(const char *, int); +struct hostent * __gethostbynisaddr(const char *, int, int); +void __map_v4v6_address(const char *, char *); +void __map_v4v6_hostent(struct hostent *, char **, char **); __END_DECLS #endif /* !_NETDB_H_ */ From owner-freebsd-arch@FreeBSD.ORG Wed May 4 22:17:16 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B7C216A4CE for ; Wed, 4 May 2005 22:17:16 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B5FB43D48 for ; Wed, 4 May 2005 22:17:15 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j44MG71h033041 for ; Wed, 4 May 2005 18:16:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j44MG77v033035 for ; Wed, 4 May 2005 18:16:07 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Wed, 4 May 2005 18:16:06 -0400 (EDT) From: Jeff Roberson To: arch@freebsd.org Message-ID: <20050504180112.M18611@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: printflike vs kprintflike X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:17:16 -0000 I have a patch from Neal Fachan of isilon that implements a new gcc attribute 'kprintflike' that is used in place of 'printflike' in the kernel. This is done to stop us from leaking kernel printf formats into userspace. Apparently -fformat-extensions is broken in gcc3. This also stops our formats from leaking into any other custom formats defined in gcc. This is available at http://www.chesapeake.net/~jroberson/kprintf.diff This patch was made against 5.4 sources with some local changes. I can update it to 6.0, but I'm hoping some compiler guru will pick it up and commit it. Thanks, Jeff From owner-freebsd-arch@FreeBSD.ORG Wed May 4 22:30:32 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 834EB16A4CE; Wed, 4 May 2005 22:30:32 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D5143D6E; Wed, 4 May 2005 22:30:32 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id D434A2A8DA; Wed, 4 May 2005 15:29:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 71832E2B3; Wed, 4 May 2005 15:29:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j44MTbBm055338; Wed, 4 May 2005 15:29:37 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j44MTaBg055337; Wed, 4 May 2005 15:29:36 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-arch@freebsd.org Date: Wed, 4 May 2005 15:29:36 -0700 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505041529.36826.peter@wemm.org> cc: arch@freebsd.org cc: standards@freebsd.org cc: current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:30:32 -0000 On Tuesday 03 May 2005 11:44 am, Hajimu UMEMOTO wrote: > To accomodate for this while preserving ABI compatibility with the > old interface, we need to prepend or append 32 bits of padding, > depending on the (LP64) architecture's endianness. I wish to delete > these padding before 6.0-RELEASE. Like David Schultz said, it would be better to use the machine/endian.h macros to set the padding position. As far as removing the padding goes, it makes little difference whether you break it now or later. Doing it now will be painful. Doing it before 6.0-REL will be just as painful. Not only is this encoded in libc.so.6, but all applications and shared libraries that have exposure to this also know it. For example, if libc.so.6 has the padding and libc.so.5 does not, and if we provide libfoo.so.1 on both 5.x and 6.x, *and* if libfoo.so.1 knows the layout of netdb.h, then it has to be bumped too. This includes all ports with shared libraries that use this #include. Otherwise running apps linked with libc.so.5 will get memory corruption. I think it would be better to leave the padding, again conditional on machine/endian.h. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed May 4 22:30:32 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 834EB16A4CE; Wed, 4 May 2005 22:30:32 +0000 (GMT) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D5143D6E; Wed, 4 May 2005 22:30:32 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id D434A2A8DA; Wed, 4 May 2005 15:29:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 71832E2B3; Wed, 4 May 2005 15:29:38 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j44MTbBm055338; Wed, 4 May 2005 15:29:37 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j44MTaBg055337; Wed, 4 May 2005 15:29:36 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-arch@freebsd.org Date: Wed, 4 May 2005 15:29:36 -0700 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505041529.36826.peter@wemm.org> cc: arch@freebsd.org cc: standards@freebsd.org cc: current@freebsd.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:30:32 -0000 On Tuesday 03 May 2005 11:44 am, Hajimu UMEMOTO wrote: > To accomodate for this while preserving ABI compatibility with the > old interface, we need to prepend or append 32 bits of padding, > depending on the (LP64) architecture's endianness. I wish to delete > these padding before 6.0-RELEASE. Like David Schultz said, it would be better to use the machine/endian.h macros to set the padding position. As far as removing the padding goes, it makes little difference whether you break it now or later. Doing it now will be painful. Doing it before 6.0-REL will be just as painful. Not only is this encoded in libc.so.6, but all applications and shared libraries that have exposure to this also know it. For example, if libc.so.6 has the padding and libc.so.5 does not, and if we provide libfoo.so.1 on both 5.x and 6.x, *and* if libfoo.so.1 knows the layout of netdb.h, then it has to be bumped too. This includes all ports with shared libraries that use this #include. Otherwise running apps linked with libc.so.5 will get memory corruption. I think it would be better to leave the padding, again conditional on machine/endian.h. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-arch@FreeBSD.ORG Wed May 4 22:47:54 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC25E16A4CE for ; Wed, 4 May 2005 22:47:54 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6672F43D3F for ; Wed, 4 May 2005 22:47:54 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 16DA646B10; Wed, 4 May 2005 18:46:33 -0400 (EDT) Date: Wed, 4 May 2005 23:50:01 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Craig Rodrigues In-Reply-To: <20050503155347.GA3768@crodrigues.org> Message-ID: <20050504234531.V40267@fledge.watson.org> References: <20050503155347.GA3768@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-arch@freebsd.org Subject: Re: Aligning extended attributes API with Mac OSX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2005 22:47:54 -0000 On Tue, 3 May 2005, Craig Rodrigues wrote: > An extended attributes API was just added to Mac OSX 10.4. This API > looks very similar to FreeBSD's. Right now there is no POSIX standard > for extended attributes, but EA are useful for many different types of > things. > > I don't know if EA are widely used in applications on FreeBSD, but what > do people think about aligning our API with Mac OSX? > > Here are the man pages for some of the API's: I've actually started looking through the kernel parts of the EA APIs, and will shortly be working my way to system calls, library calls, etc. It is my intent to adopt more widely used APIs as appropriate -- when I added EA APIs to FreeBSD, the only comparable APIs I knew of were the HPFS extended attribute model, and the SGI XFS model. I modeled our EA semantics on the SGI model, following meetings and e-mail exchanges with members of SGI's trusted OS group. I had hoped that we'd pursuade others to pick up our APIs, such as the Linux ACL and capability developers, but apparently I was unsuccessful in doing that, although we did reach concensus on elements of the POSIX.1e draft ACL APIs in a number of areas. So this is something I am willing and happy to look at; we'll need to go through a proper deprecation cycle, and it will happen time permitting. If you're interested in looking into the details and summarizing the specific changes, that might be quite helpful. In particular, one of the more important aspects of our design, derived from SGI's design, is the association of protection properties with "name spaces". I.e., a system name space that requires privilege to manipulate, so can hold system maintained properties, such as ACLs and MAC labels, vs a user name space, which is protected using the normal permissions/ACLs on a file, permitting users to modify the contents. Determining to what extent protections are handled/managed in the Darwin model will be important. I'm scheduled to visit Apple shortly after BSDCan to talk about these and related issues -- if you come up with specific questions or concerns before then, I can raise them during my visit. Robert N M Watson > > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/listxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/setxattr.2.html > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/removexattr.2.html#//apple_ref/doc/man/2/removexattr > http://developer.apple.com/documentation/Darwin/Reference/ManPages/man2/getxattr.2.html#//apple_ref/doc/man/2/getxattr > > > The FreeBSD equivalents are documented in extattr(2). > > -- > Craig Rodrigues > rodrigc@crodrigues.org > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Thu May 5 00:05:05 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D022816A4CE for ; Thu, 5 May 2005 00:05:05 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8469343D64 for ; Thu, 5 May 2005 00:05:04 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw501.dsto.defence.gov.au (ednmsw501.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j4501Pgk016431 for ; Thu, 5 May 2005 09:31:25 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw501.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.17) with ESMTP id for ; Thu, 5 May 2005 09:32:53 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j44NuC026030 for ; Thu, 5 May 2005 09:26:12 +0930 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id J84NPQJB; Thu, 5 May 2005 09:26:01 +0930 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j4500iLc028181 for ; Thu, 5 May 2005 09:30:44 +0930 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j4500ioC028180 for freebsd-arch@freebsd.org; Thu, 5 May 2005 09:30:44 +0930 (CST) (envelope-from wilkinsa) Date: Thu, 5 May 2005 09:30:44 +0930 From: "Wilkinson, Alex" To: freebsd-arch@freebsd.org Message-ID: <20050505000041.GA28165@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-arch@freebsd.org References: <20050503155347.GA3768@crodrigues.org> <20050504234531.V40267@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20050504234531.V40267@fledge.watson.org> User-Agent: Mutt/1.5.6i Subject: Re: Aligning extended attributes API with Mac OSX? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 00:05:06 -0000 0n Wed, May 04, 2005 at 11:50:01PM +0100, Robert Watson wrote: > >On Tue, 3 May 2005, Craig Rodrigues wrote: > >>An extended attributes API was just added to Mac OSX 10.4. This API >>looks very similar to FreeBSD's. Right now there is no POSIX standard >>for extended attributes, but EA are useful for many different types of >>things. >> >>I don't know if EA are widely used in applications on FreeBSD, but what >>do people think about aligning our API with Mac OSX? >> >>Here are the man pages for some of the API's: > >I've actually started looking through the kernel parts of the EA APIs, and >will shortly be working my way to system calls, library calls, etc. It is >my intent to adopt more widely used APIs as appropriate -- when I added EA >APIs to FreeBSD, the only comparable APIs I knew of were the HPFS extended >attribute model, and the SGI XFS model. I modeled our EA semantics on the >SGI model, following meetings and e-mail exchanges with members of SGI's >trusted OS group. I had hoped that we'd pursuade others to pick up our >APIs, such as the Linux ACL and capability developers, but apparently I >was unsuccessful in doing that, although we did reach concensus on >elements of the POSIX.1e draft ACL APIs in a number of areas. > >So this is something I am willing and happy to look at; we'll need to go >through a proper deprecation cycle, and it will happen time permitting. >If you're interested in looking into the details and summarizing the >specific changes, that might be quite helpful. In particular, one of the >more important aspects of our design, derived from SGI's design, is the >association of protection properties with "name spaces". I.e., a system >name space that requires privilege to manipulate, so can hold system >maintained properties, such as ACLs and MAC labels, vs a user name space, >which is protected using the normal permissions/ACLs on a file, permitting >users to modify the contents. Determining to what extent protections are >handled/managed in the Darwin model will be important. > >I'm scheduled to visit Apple shortly after BSDCan to talk about these and >related issues -- if you come up with specific questions or concerns >before then, I can raise them during my visit. FYI there is a solid review of Tiger at arstechnica (109 pages). Here is the section on macos-x's EA: [http://arstechnica.com/reviews/os/macosx-10.4.ars/7] - aW From owner-freebsd-arch@FreeBSD.ORG Thu May 5 02:56:12 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F2D516A4CE for ; Thu, 5 May 2005 02:56:12 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2E9743D39; Thu, 5 May 2005 02:56:11 +0000 (GMT) (envelope-from kan@FreeBSD.org) Received: from freefall.freebsd.org (kan@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j452tAXp003181; Thu, 5 May 2005 02:55:10 GMT (envelope-from kan@freefall.freebsd.org) Received: (from kan@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j452tASC003180; Thu, 5 May 2005 02:55:10 GMT (envelope-from kan) Date: Thu, 5 May 2005 02:55:10 +0000 From: Alexander Kabaev To: Jeff Roberson Message-ID: <20050505025509.GA3120@freefall.freebsd.org> References: <20050504180112.M18611@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050504180112.M18611@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i cc: arch@freebsd.org Subject: Re: printflike vs kprintflike X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 02:56:12 -0000 On Wed, May 04, 2005 at 06:16:06PM -0400, Jeff Roberson wrote: > I have a patch from Neal Fachan of isilon that implements a new gcc > attribute 'kprintflike' that is used in place of 'printflike' in the > kernel. This is done to stop us from leaking kernel printf formats into > userspace. Apparently -fformat-extensions is broken in gcc3. This also > stops our formats from leaking into any other custom formats defined in > gcc. > I would like to avoid introduction of a new printf attribute if possible. Does fixed -fformat-extensions suffice your needs? If so, can you try the patch below instead? Index: c-common.h =================================================================== RCS file: /home/ncvs/src/contrib/gcc/c-common.h,v retrieving revision 1.7 diff -u -r1.7 c-common.h --- c-common.h 28 Jul 2004 03:46:02 -0000 1.7 +++ c-common.h 5 May 2005 02:45:10 -0000 @@ -840,6 +840,9 @@ /* Nonzero means the expression being parsed will never be evaluated. This is a count, since unevaluated expressions can nest. */ +/* Nonzero allows FreeBSD kenrel-specific printf formats. */ +extern int flag_format_extensions; + extern int skip_evaluation; /* C types are partitioned into three subsets: object, function, and Index: c-format.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/c-format.c,v retrieving revision 1.9 diff -u -r1.9 c-format.c --- c-format.c 28 Jul 2004 03:57:21 -0000 1.9 +++ c-format.c 5 May 2005 02:33:31 -0000 @@ -257,7 +257,8 @@ STD_C94, STD_C9L, /* C99, but treat as C89 if -Wno-long-long. */ STD_C99, - STD_EXT + STD_EXT, + STD_BSD }; /* The C standard version C++ is treated as equivalent to @@ -785,9 +786,9 @@ ("%6D", ptr, ":") -> XX:XX:XX:XX:XX:XX ("%*D", len, ptr, " ") -> XX XX XX XX ... */ - { "D", 1, STD_EXT, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp", "cR" }, - { "b", 1, STD_EXT, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp", "" }, - { "ry", 0, STD_EXT, { T89_I, BADLEN, BADLEN, T89_L, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp0 +#", "i" }, + { "D", 1, STD_BSD, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp", "cR" }, + { "b", 1, STD_BSD, { T89_C, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp", "" }, + { "ry", 0, STD_BSD, { T89_I, BADLEN, BADLEN, T89_L, BADLEN, BADLEN, BADLEN, BADLEN, BADLEN }, "-wp0 +#", "i" }, { NULL, 0, 0, NOLENGTHS, NULL, NULL } }; @@ -2091,7 +2092,8 @@ format_chars++; fci = fki->conversion_specs; while (fci->format_chars != 0 - && strchr (fci->format_chars, format_char) == 0) + && (strchr (fci->format_chars, format_char) == 0 || + (!flag_format_extensions && fci->std == STD_BSD))) ++fci; if (fci->format_chars == 0) { Index: c-opts.c =================================================================== RCS file: /home/ncvs/src/contrib/gcc/c-opts.c,v retrieving revision 1.2 diff -u -r1.2 c-opts.c --- c-opts.c 29 Jul 2004 02:04:58 -0000 1.2 +++ c-opts.c 5 May 2005 02:41:26 -0000 @@ -1047,6 +1047,7 @@ break; case OPT_fformat_extensions: + flag_format_extensions = value; break; } From owner-freebsd-arch@FreeBSD.ORG Thu May 5 09:04:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D818816A4CE; Thu, 5 May 2005 09:04:34 +0000 (GMT) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3ED6443DAC; Thu, 5 May 2005 09:04:34 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86])j4594MkG023144; Thu, 5 May 2005 19:04:22 +1000 Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) j4594Kx7005348; Thu, 5 May 2005 19:04:21 +1000 Date: Thu, 5 May 2005 19:04:21 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Alexander Kabaev In-Reply-To: <20050505025509.GA3120@freefall.freebsd.org> Message-ID: <20050505184727.A1664@epsplex.bde.org> References: <20050504180112.M18611@mail.chesapeake.net> <20050505025509.GA3120@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: arch@freebsd.org Subject: Re: printflike vs kprintflike X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 May 2005 09:04:35 -0000 On Thu, 5 May 2005, Alexander Kabaev wrote: > On Wed, May 04, 2005 at 06:16:06PM -0400, Jeff Roberson wrote: >> I have a patch from Neal Fachan of isilon that implements a new gcc >> attribute 'kprintflike' that is used in place of 'printflike' in the >> kernel. This is done to stop us from leaking kernel printf formats into >> userspace. Apparently -fformat-extensions is broken in gcc3. This also >> stops our formats from leaking into any other custom formats defined in >> gcc. >> > > I would like to avoid introduction of a new printf attribute if possible. > Does fixed -fformat-extensions suffice your needs? If so, can you try the > patch below instead? -fformat-extensions was intended for this. > Index: c-common.h > =================================================================== > RCS file: /home/ncvs/src/contrib/gcc/c-common.h,v > retrieving revision 1.7 > diff -u -r1.7 c-common.h > --- c-common.h 28 Jul 2004 03:46:02 -0000 1.7 > +++ c-common.h 5 May 2005 02:45:10 -0000 > @@ -840,6 +840,9 @@ > /* Nonzero means the expression being parsed will never be evaluated. > This is a count, since unevaluated expressions can nest. */ > > +/* Nonzero allows FreeBSD kenrel-specific printf formats. */ Spelling. > +extern int flag_format_extensions; > + > extern int skip_evaluation; > > /* C types are partitioned into three subsets: object, function, and > Index: c-format.c > =================================================================== > RCS file: /home/ncvs/src/contrib/gcc/c-format.c,v > retrieving revision 1.9 > diff -u -r1.9 c-format.c > --- c-format.c 28 Jul 2004 03:57:21 -0000 1.9 > +++ c-format.c 5 May 2005 02:33:31 -0000 > @@ -257,7 +257,8 @@ > STD_C94, > STD_C9L, /* C99, but treat as C89 if -Wno-long-long. */ > STD_C99, > - STD_EXT > + STD_EXT, > + STD_BSD > }; > > /* The C standard version C++ is treated as equivalent to -fformat-extensions was also intended to unextend (sic) to the formats that are actually supported by the kernel printf. I never got around to implementing this. It is now easier to implement, but not as easy as it should be (the enums in the above should be bitmaps ...). The kernel printf doesn't support floating point formats, at least, and shouldn't support mistakes like %q and %ll. Bruce From owner-freebsd-arch@FreeBSD.ORG Fri May 6 12:57:30 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6536C16A4D4 for ; Fri, 6 May 2005 12:57:30 +0000 (GMT) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 175EB43D8D for ; Fri, 6 May 2005 12:57:30 +0000 (GMT) (envelope-from fteg@london.com) Received: from unknown (unknown [192.168.9.180])0734618001BD for ; Fri, 6 May 2005 12:57:30 +0000 (GMT) X-OB-Received: from unknown (205.158.62.49) by wfilter.us4.outblaze.com; 6 May 2005 12:57:29 -0000 Received: by ws1-1.us4.outblaze.com (Postfix, from userid 1001) id DF5D94BEAD; Fri, 6 May 2005 12:57:29 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [213.187.181.70] by ws1-1.us4.outblaze.com with http for fteg@london.com; Fri, 06 May 2005 07:57:29 -0500 From: "Fafa Hafiz Krantz" To: questions@freebsd.org, arch@freebsd.org Date: Fri, 06 May 2005 07:57:29 -0500 X-Originating-Ip: 213.187.181.70 X-Originating-Server: ws1-1.us4.outblaze.com Message-Id: <20050506125729.DF5D94BEAD@ws1-1.us4.outblaze.com> Subject: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 12:57:30 -0000 Hello. For you all meticulous cats out there, here's how I hope that FreeBSD's dmesg one day can look like. This is merely a beautification that would make more people go "wow, cool" and it doesn't deprive FreeBSD of its UNIX heritage. Perhaps someone out there can help me implement these changes? I have a lot more suggestions for ASCII redesigns, so let me know! # dmesg (imaginary) # Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reser= ved. FreeBSD 5.4-STABLE #0: Thu May 5 22:54:49 CEST 2005 fafa@ninja.domain.com:/usr/obj/usr/src/sys/NINJA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P54C (119.75-MHz 586-class CPU) Origin =3D GenuineIntel, Id =3D 0x52c, Stepping =3D 12 Features =3D 0x1bf Real memory =3D 100663296 (96 MB) Available memory =3D 93036544 (88 MB) Intel Pentium detected, installing work-around for F00F bug npx0: Math processor> on motherboard npx0: INT 16 interface cpu0: Attached to motherboard pcib0: Host to PCI bridge, pcibus 0 on motherboard pci0: PCI bus, on pcib0 isab0: PCI-ISA bridge, at device 7.0 on pci0 isa0: ISA bus, on isab0 pci0: VGA display, at device 8.0 (no driver attached) lnc0: PCNet/PCI ethernet adapter, port 0xff80-0xff9f irq 10 at device 11= .0 on pci0 lnc0: Attached to PCNet/PCI ethernet adapter lnc0: Ethernet address: 00:00:4b:30:1e:94 lnc0: if_start running deferred for Giant lnc0: PCnet-PCI pci0: Multimedia (audio), at device 17.0 (no driver attached) pci0: VGA display, at device 19.0 (no driver attached) orm0: ISA Option ROMs, at iomem 0xed000-0xedfff,0xc0000-0xc7fff on isa0 ata0: Attached to port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1: Attached to port 0x376,0x170-0x177 irq 15 on isa0 atkbdc0: Keyboard controller (i8042), at port 0x64,0x60 on isa0 atkbd0: AT keyboard, irq 1 on atkbdc0 kbd0: Attached to atkbd0 fdc0: Enhanced floppy controller, at port 0x3f0-0x3f5 irq 6 drq 2 on i= sa0 fd0: 1440-KB 3.5" drive, on fdc0 drive 0 sc0: System console, at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0: Attached to port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: Type 16550A sio1: Configured irq 3 not in bitmap of probed irqs 0 sio1: Port may not be enabled vga0: Generic ISA VGA, at port 0x3c0-0x3df iomem 0xa0000-0xbffff on is= a0 ep0: 3Com 3C509B-Combo EtherLink III (PnP), at port 0x210-0x21f irq 3= on isa0 ep0: Ethernet address: 00:a0:24:1b:2b:a6 ad0: 38166MB [77545/16/63] at ata0-mast= er PIO4 Timecounter "TSC" frequency 119753009 Hz quality 800 Timecounters tick every 10.000 msec Mounting root from ufs:/dev/ad0s1a # dmesg (actual) # Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #0: Thu May 5 22:54:49 CEST 2005 fafa@ninja.domain.com:/usr/obj/usr/src/sys/NINJA Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P54C (119.75-MHz 586-class CPU) Origin =3D "GenuineIntel" Id =3D 0x52c Stepping =3D 12 Features=3D0x1bf real memory =3D 100663296 (96 MB) avail memory =3D 93036544 (88 MB) Intel Pentium detected, installing workaround for F00F bug npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 8.0 (no driver attached) lnc0: port 0xff80-0xff9f irq 10 at device 11.0= on pci0 lnc0: Attaching PCNet/PCI Ethernet adapter lnc0: Ethernet address: 00:00:4b:30:1e:94 lnc0: if_start running deferred for Giant lnc0: PCnet-PCI pci0: at device 17.0 (no driver attached) pci0: at device 19.0 (no driver attached) orm0: at iomem 0xed000-0xedfff,0xc0000-0xc7fff on isa0 ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ep0: <3Com 3C509B-Combo EtherLink III (PnP)> at port 0x210-0x21f irq 3 on i= sa0 ep0: Ethernet address: 00:a0:24:1b:2b:a6 unknown: can't assign resources (port) psmcpnp0: irq resource info is missing; assuming irq 12 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 119753009 Hz quality 800 Timecounters tick every 10.000 msec ad0: 38166MB [77545/16/63] at ata0-master PIO4 Mounting root from ufs:/dev/ad0s1a See the difference. Appreciate the difference. Commit the difference. Thanks! -- Fafa Hafiz Krantz Research Designer @ http://www.home.no/barbershop Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-freebsd-arch@FreeBSD.ORG Fri May 6 18:14:05 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1923616A4D4; Fri, 6 May 2005 18:14:05 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id C022A43D9B; Fri, 6 May 2005 18:14:04 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j46IE42Q076361; Fri, 6 May 2005 13:14:04 -0500 (CDT) (envelope-from dan) Date: Fri, 6 May 2005 13:14:04 -0500 From: Dan Nelson To: Fafa Hafiz Krantz Message-ID: <20050506181404.GG49336@dan.emsphone.com> References: <20050506125729.DF5D94BEAD@ws1-1.us4.outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050506125729.DF5D94BEAD@ws1-1.us4.outblaze.com> X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.8i cc: arch@freebsd.org cc: questions@freebsd.org Subject: Re: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 18:14:05 -0000 In the last episode (May 06), Fafa Hafiz Krantz said: > For you all meticulous cats out there, here's how I hope that > FreeBSD's dmesg one day can look like. This is merely a > beautification that would make more people go "wow, cool" and it > doesn't deprive FreeBSD of its UNIX heritage. > > Perhaps someone out there can help me implement these changes? I have > a lot more suggestions for ASCII redesigns, so let me know! > > ata0: Attached to port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 > ata1: Attached to port 0x376,0x170-0x177 irq 15 on isa0 > atkbdc0: Keyboard controller (i8042), at port 0x64,0x60 on isa0 It's easy enough to change the format string in subr_bus.c:device_print_prettyname() to pad out the devicename. However, you may prefer to just put up a splash screen (see the splash manpage), so the user doesn't even see the kernel messages at all. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-arch@FreeBSD.ORG Fri May 6 18:27:53 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 186AA16A4D4; Fri, 6 May 2005 18:27:53 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE7543D39; Fri, 6 May 2005 18:27:52 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j46IQfht009166; Fri, 6 May 2005 12:26:41 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 06 May 2005 12:26:41 -0600 (MDT) Message-Id: <20050506.122641.78716734.imp@bsdimp.com> To: dnelson@allantgroup.com From: Warner Losh In-Reply-To: <20050506181404.GG49336@dan.emsphone.com> References: <20050506125729.DF5D94BEAD@ws1-1.us4.outblaze.com> <20050506181404.GG49336@dan.emsphone.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: questions@freebsd.org cc: fteg@london.com Subject: Re: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 18:27:53 -0000 From: Dan Nelson Subject: Re: A beautiful dmesg! Maybe one day? Date: Fri, 6 May 2005 13:14:04 -0500 > In the last episode (May 06), Fafa Hafiz Krantz said: > > For you all meticulous cats out there, here's how I hope that > > FreeBSD's dmesg one day can look like. This is merely a > > beautification that would make more people go "wow, cool" and it > > doesn't deprive FreeBSD of its UNIX heritage. > > > > Perhaps someone out there can help me implement these changes? I have > > a lot more suggestions for ASCII redesigns, so let me know! > > > > ata0: Attached to port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 > > ata1: Attached to port 0x376,0x170-0x177 irq 15 on isa0 > > atkbdc0: Keyboard controller (i8042), at port 0x64,0x60 on isa0 > > It's easy enough to change the format string in > subr_bus.c:device_print_prettyname() to pad out the devicename. > However, you may prefer to just put up a splash screen (see the splash > manpage), so the user doesn't even see the kernel messages at all. Many of his suggestions are subtle changes to the probe messages in addition to the format string. Warner From owner-freebsd-arch@FreeBSD.ORG Fri May 6 19:20:23 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 820D916A4D6 for ; Fri, 6 May 2005 19:20:23 +0000 (GMT) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47BAC43D9F for ; Fri, 6 May 2005 19:20:23 +0000 (GMT) (envelope-from fteg@london.com) Received: from unknown (unknown [192.168.9.180])ED1C018001D2 for ; Fri, 6 May 2005 19:20:22 +0000 (GMT) X-OB-Received: from unknown (205.158.62.49) by wfilter.us4.outblaze.com; 6 May 2005 19:20:22 -0000 Received: by ws1-1.us4.outblaze.com (Postfix, from userid 1001) id A45F64BEAE; Fri, 6 May 2005 19:20:22 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [213.187.181.70] by ws1-1.us4.outblaze.com with http for fteg@london.com; Fri, 06 May 2005 14:20:22 -0500 From: "Fafa Hafiz Krantz" To: "Warner Losh" , dnelson@allantgroup.com Date: Fri, 06 May 2005 14:20:22 -0500 X-Originating-Ip: 213.187.181.70 X-Originating-Server: ws1-1.us4.outblaze.com Message-Id: <20050506192022.A45F64BEAE@ws1-1.us4.outblaze.com> cc: arch@freebsd.org cc: questions@freebsd.org Subject: Re: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 19:20:23 -0000 Hello Mr. Nelson and Mr. Losh! > It's easy enough to change the format string in > subr_bus.c:device_print_prettyname() to pad out the devicename. I am not qualified to do this. I wish I were. How about you guys? :) =20 > However, you may prefer to just put up a splash screen (see the=20 > splash manpage), so the user doesn't even see the kernel messages > at all. We can't just forget about it and pray for it to go away. This is an aesthetic violation to FreeBSD's professional image, that is considered to be more important now than ever. Now that we have logo and website design competitions going to completely revamp of the FreeBSD of the 70s, perhaps it's also time to update the ASCII design of this system? > Many of his suggestions are subtle changes to the probe messages in > addition to the format string. >=20 > Warner Indeed they are subtle. But it's more like removing zits. With laser or whatever. :) -- Fafa Hafiz Krantz Research Designer @ http://www.home.no/barbershop Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm From owner-freebsd-arch@FreeBSD.ORG Fri May 6 19:44:17 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 274A916A4D4 for ; Fri, 6 May 2005 19:44:17 +0000 (GMT) Received: from isilon.com (isilon.com [65.101.129.58]) by mx1.FreeBSD.org (Postfix) with SMTP id A988A43D8B for ; Fri, 6 May 2005 19:44:16 +0000 (GMT) (envelope-from neal@isilon.com) Received: (qmail 86285 invoked by uid 1001); 6 May 2005 19:43:51 -0000 Date: Fri, 6 May 2005 12:43:51 -0700 From: Neal Fachan To: Alexander Kabaev Message-ID: <20050506194351.GB68900@isilon.com> References: <20050504180112.M18611@mail.chesapeake.net> <20050505025509.GA3120@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050505025509.GA3120@freefall.freebsd.org> User-Agent: Mutt/1.4.1i cc: arch@freebsd.org Subject: Re: printflike vs kprintflike X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2005 19:44:17 -0000 On Thu, May 05, 2005 at 02:55:10AM +0000, Alexander Kabaev wrote: > On Wed, May 04, 2005 at 06:16:06PM -0400, Jeff Roberson wrote: > > I have a patch from Neal Fachan of isilon that implements a new gcc > > attribute 'kprintflike' that is used in place of 'printflike' in the > > kernel. This is done to stop us from leaking kernel printf formats into > > userspace. Apparently -fformat-extensions is broken in gcc3. This also > > stops our formats from leaking into any other custom formats defined in > > gcc. > > > > I would like to avoid introduction of a new printf attribute if possible. > Does fixed -fformat-extensions suffice your needs? If so, can you try the > patch below instead? I assume that you're interested in not changing all the __printflike's to __kprintflike's? That seems like a good goal, and it certainly eases upgrading. The are a few problems with your patch. First, as Bruce points out, there are other differences between the kernel's printf and userspace's printf. One difference is that the floating point formats aren't supported. Another is that some of the flags are different (' ' isn't supported, for example). The second problem is the explicit checks for 'b' and 'D' later in check_format_info_main. These checks remove the first argument (of two) for these format specifiers. However, if there is another format type which also uses either of these characters, there will be a conflict (strftime's %D, for example). How about the approach of having two different format tables (format_kind_info's), one for kprintf and one for printf, and then choosing the appropriate one based on the flag_format_extensions? I'll code something up today and send a patch. Thanks. -Neal -- Neal Fachan neal@isilon.com From owner-freebsd-arch@FreeBSD.ORG Sat May 7 02:40:19 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38CDA16A4D4; Sat, 7 May 2005 02:40:19 +0000 (GMT) Received: from S2.cableone.net (smtp2.cableone.net [24.116.0.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id C94BE43D86; Sat, 7 May 2005 02:40:18 +0000 (GMT) (envelope-from v.velox@vvelox.net) Received: from vixen42.local.lan (unverified [24.119.123.39]) by S2.cableone.net (CableOne SMTP Service S2) with ESMTP id 19024708 for multiple; Fri, 06 May 2005 20:09:05 -0700 Date: Sat, 7 May 2005 21:40:03 -0500 From: Vulpes Velox To: "Fafa Hafiz Krantz" Message-ID: <20050507214003.7cac15a0@vixen42.local.lan> In-Reply-To: <20050506192022.A45F64BEAE@ws1-1.us4.outblaze.com> References: <20050506192022.A45F64BEAE@ws1-1.us4.outblaze.com> X-Mailer: Sylpheed-Claws 1.0.4 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IP-stats: Incoming Last 0, First 8, in=12, out=0, spam=0 X-External-IP: 24.119.123.39 X-Abuse-Info: Send abuse complaints to abuse@cableone.net cc: arch@freebsd.org cc: questions@freebsd.org cc: dnelson@allantgroup.com Subject: Re: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 02:40:19 -0000 On Fri, 06 May 2005 14:20:22 -0500 "Fafa Hafiz Krantz" wrote: > > Hello Mr. Nelson and Mr. Losh! > > > It's easy enough to change the format string in > > subr_bus.c:device_print_prettyname() to pad out the devicename. > > I am not qualified to do this. I wish I were. > How about you guys? :) > > > However, you may prefer to just put up a splash screen (see the > > splash manpage), so the user doesn't even see the kernel messages > > at all. > > We can't just forget about it and pray for it to go away. > > This is an aesthetic violation to FreeBSD's professional image, > that is considered to be more important now than ever. > > Now that we have logo and website design competitions going to > completely revamp of the FreeBSD of the 70s, perhaps it's also time > to update the ASCII design of this system? I personally find the old methode a lot easier to read, compared to the new one. If a change is wanted, why not make such a thing like this a kernel option? > > Many of his suggestions are subtle changes to the probe messages > > in addition to the format string. > > > > Warner > > Indeed they are subtle. > But it's more like removing zits. With laser or whatever. From owner-freebsd-arch@FreeBSD.ORG Sat May 7 11:05:57 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AD1416A4D9 for ; Sat, 7 May 2005 11:05:57 +0000 (GMT) Received: from webmail-outgoing.us4.outblaze.com (webmail-outgoing.us4.outblaze.com [205.158.62.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AA7643D62 for ; Sat, 7 May 2005 11:05:57 +0000 (GMT) (envelope-from fteg@london.com) Received: from unknown (unknown [192.168.9.180])1AFCD18001CA for ; Sat, 7 May 2005 11:05:57 +0000 (GMT) X-OB-Received: from unknown (205.158.62.49) by wfilter.us4.outblaze.com; 7 May 2005 11:05:57 -0000 Received: by ws1-1.us4.outblaze.com (Postfix, from userid 1001) id 05A284BEAD; Sat, 7 May 2005 11:05:57 +0000 (GMT) Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Received: from [213.187.181.70] by ws1-1.us4.outblaze.com with http for fteg@london.com; Sat, 07 May 2005 06:05:56 -0500 From: "Fafa Hafiz Krantz" To: "Vulpes Velox" Date: Sat, 07 May 2005 06:05:56 -0500 X-Originating-Ip: 213.187.181.70 X-Originating-Server: ws1-1.us4.outblaze.com Message-Id: <20050507110557.05A284BEAD@ws1-1.us4.outblaze.com> cc: arch@freebsd.org cc: questions@freebsd.org cc: dnelson@allantgroup.com Subject: Re: A beautiful dmesg! Maybe one day? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 May 2005 11:05:57 -0000 Hey! > I personally find the old methode a lot easier to read, compared to > the new one. If a change is wanted, why not make such a thing like > this a kernel option? Are you referring to the indenting? Yeah your eyes would have to jump. A sacrifice necessary for order. But the changes were not only in the indenting. They were logical changes to areas that seemed neglected. You should do a diff! Take care :) -- Fafa Hafiz Krantz Research Designer @ http://www.home.no/barbershop Enlightened @ http://www.home.no/barbershop/smart/sharon.pdf --=20 ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm