From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2526 Path: news.gmane.org!not-for-mail From: Brad Conroy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Agenda for next release? Date: Mon, 31 Dec 2012 13:37:39 -0800 (PST) Message-ID: <1356989859.15084.YahooMailClassic@web160406.mail.bf1.yahoo.com> References: <20121231191131.GA18334@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="1741458154-770386030-1356989859=:15084" X-Trace: ger.gmane.org 1356989872 6278 80.91.229.3 (31 Dec 2012 21:37:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Dec 2012 21:37:52 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2527-gllmg-musl=m.gmane.org@lists.openwall.com Mon Dec 31 22:38:08 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Tpn3f-0007WM-Ii for gllmg-musl@plane.gmane.org; Mon, 31 Dec 2012 22:38:07 +0100 Original-Received: (qmail 17909 invoked by uid 550); 31 Dec 2012 21:37:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17898 invoked from network); 31 Dec 2012 21:37:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 772942.42581.bm@omp1009.mail.bf1.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1356989859; bh=tWMpUiQwU0s8EivPQipBWwDyfrKFEEj1jWq5dvx48YQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=kUJQcpyd5pi6lVjmXbZBcg3GLzU/ODtas8jvbfizZJgT+Q8xe132hhkw5wlFy8lEHsCKT+5H4oNVarPTiEoRNYmDXdSfJMKrhs0AdKVMEU3xYZ+xPMCzT4nSnLmpF7NKOvY3Ee0nsMZaEiYwTc2myNJm4zVCIJ0DWM3yNcrpW6M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=ewufSr+dn/X2yyDe1XGXJX8SpnJ4dxWjizellwcp/K921D7Npz1lvIieeOFauYGzrNkGO846MwXgMn5PL/UhL/eaUsTzhPin3E+aUIQ6JM+eIqGofi8tT8r3eVuAlfLb06em1/SyMYv0w8XRLuD0H2A+w+cZedNgTpoqsxtqNtI=; X-YMail-OSG: ArlfCuEVM1kRqtXVvRABEgecXLVxLsfm_CLzDYyDZYioT5p _uD0JlKrRNjypDoz42NBjIEBUCFB.AInSSFiVs6JPMx63prCO1vfsAop0lz5 bHhTOHsgXtjCEhHT3kXOiaDsGrq7k4yJps5uWzUsYYUSMDjoPUs0Qz6AMuWX eGkQaR0E_WoosFgFCGYUOs0ZLbuVeVTHHyYtlcS9.56QQT4s5k2TwCfct9xS GEh6tWfrNKYXScjVRmQdtyOShCq.QqJsqTCwooOvhdlv5l8JuMZiPtangChY Wiq9dJgbbXwKU1mEpVZ8dORvF6P7uN9VU2vBNdH9vvZJnW4vYOM5MeSAc4U3 fdaRpsI5uQ4RHRPyrxa5tJuAKM4PPlm7J7nP1gMDmDrH_MjJvKFX38WNhEVG pD0ovuYSE9gD3051V9PfCdlDjikjfBH9tlHV6aOwm.XJhwLYcaJDQbiFixQ6 dFU618sPuErCL9jUz9NDB7vmYYceqW_xu3vsutzyVi7GuCtjsSIACsEEVbLl w.WhEPauRSsOfZm0n_aT6TR7pNpZ3DZt1YruPaBcH5seHguzt6_A3F9nmVgC 2XSj8QiHaq1GUctST40XoIfK0gVBJ8xeVn2lXiACVdVQlUa2qjZ529Lb6zuj Q6qKjhN_XedeXLnNjoiQuX.EC5Sw- X-Rocket-MIMEInfo: 001.001,Tm90IGZ1bmN0aW9uYWxseSBuZWNlc3NhcnkgZm9yIHRoZSByZWxlYXNlLCBidXQgbmljZSBmb3IgZnV0dXJlIGNvbXBhdGliaWxpdHkgcmVhc29ucywgYSBmZXcgcGF0aHMgYXJlIGhhcmQtY29kZWQgaW50byB0aGUgYyBmaWxlcyByYXRoZXIgdGhhbiBkZWZpbmluZyB0aGVtIGluIHRoZSAobm9uLSkic3RhbmRhcmQiIGxvY2F0aW9uDQpFeC5zcmMvbmV0d29yay9nZXRhZGRyaW5mby5jIGhhcyAiL2V0Yy9ob3N0cyIsICIvZXRjL3Jlc29sdmUuY29uZiIgYW5kICIvZXRjL3NlcnZpY2VzIiBoYXJkLWNvZGVkIHIBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.129.483 In-Reply-To: <20121231191131.GA18334@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2526 Archived-At: --1741458154-770386030-1356989859=:15084 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Not functionally necessary for the release, but nice for future compatibili= ty reasons, a few paths are hard-coded into the c files rather than definin= g them in the (non-)"standard" location Ex.src/network/getaddrinfo.c has "/etc/hosts", "/etc/resolve.conf" and "/et= c/services" hard-coded rather than defining them in netdb.h #define _PATH_HOSTS "/etc/hosts"#define _PATH_NSSWITCH_CONF "/etc/nsswitch.= conf"#define _PATH_SERVICES "/etc/services" also defined in netdb.h for other uses #define _PATH_HEQUIV "/etc/hosts.equiv"#define _PATH_NETWORKS "/etc/network= s"#define _PATH_PROTOCOLS "/etc/protocols" resolv.h does have=A0#define _PATH_RESCONF=A0"/etc/resolve.conf" however=A0= src/network/__dns.c still has the hard-coded path also I'm sure there are others that grep could find (fstab.h,paths.h,ttyent.h xt= ables.h,???) also android has etc in /system, so the actual path is=A0/system/etc/hosts = (though /etc is typically a symlink to /system/etc), but other strange layo= uts exist and it would be a lot easier/cleaner for work arounds to have the= ifdefs confined to one location in the header files and use those definiti= ons in the .c files so that port patches only hit a few headers without pol= luting the .c files with a lot of ifdef nests I ran into this while building a static wget-like downloader that would use= an alternate hosts file to complement a custom local server that locally h= osts some problematic CDNs (to work around problems such as: waiting for aj= ax.googleapis.com, platform.twitter.com etc...) but this is an obvious hack= , not the typical use case for a standard library... but then again part of= the charm of musl is its "hackability" --- On Mon, 12/31/12, Rich Felker wrote: From: Rich Felker Subject: [musl] Agenda for next release? To: musl@lists.openwall.com Date: Monday, December 31, 2012, 2:11 PM Hi, I don't have any immediate plan for the next release, but I'd like to start thinking about what we'd like to go into it. A few things I know are still pending that should be possible to include are: - strverscmp - zoneinfo - inet_makeaddr - scanf %m modifier - getifaddrs - cpuset/affinity interfaces - ether.h interfaces I know there's also interest in exposing sigreturn and setcontext for libunwind use, but it's difficult to do right and I'm really skeptical of the whole thing. Their use of sigreturn seems completely incorrect (and thus probably untested); sigreturn expects a struct sigcontext on the stack, not a pointer to a sigcontext in the first function argument slot. I would rather have a conversation with their developers first to determine if that code is even working/valid, and defer the corresponding additions to musl until we eventually add all the ucontext.h interfaces in working form. Another port (perhaps x32, like originally proposed) is also definitely an option if anybody's up for doing it. I had considered doing it myself in this release cycle, but I'm a bit busy with some other projects for at least a couple weeks so I'd rather not get bogged down in a big time-eater right away, and instead spend my time with musl on small isolated feature additions and bug fixes. Anything else I missed? Rich --1741458154-770386030-1356989859=:15084 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Not functionally necessary for the release, but nice for future comp= atibility reasons, a few paths are hard-coded into the c files rather than = defining them in the (non-)"standard" location

Ex.
src/network/getaddrinfo.c has "/etc/hosts", "/etc/resolve.conf" and "/e= tc/services" hard-coded rather than defining them in netdb.h<= div style=3D"font-family: arial; font-size: 10pt;">
#define _PATH_HOSTS "/etc/hosts"
#define _PATH_NSSWITCH= _CONF "/etc/nsswitch.conf"
#define _PATH_SERVICES "/etc/services"

also defined in netdb.h for other uses

#define _PATH_HEQUIV "/etc/h= osts.equiv"
#defin= e _PATH_NETWORKS "/etc/networks"
#define _PATH_PROTOCOLS "/etc/protocols"

resolv.h doe= s have #define _PATH_RESCONF "/etc/resolve.conf" however src/network/__dns.c still has the hard-c= oded path also

I'm sure there are others that grep could find (fstab.h,paths.h,tty= ent.h xtables.h,???)

<= span style=3D"font-size: 13px;">also android has etc in /system, so the act= ual path is /system/etc/hosts (though /etc is typically a symlink to= /system/etc), but other strange layouts exist and it would be a lot easier= /cleaner for work arounds to have the ifdefs confined to one location in th= e header files and use those definitions in the .c files so that port patch= es only hit a few headers without polluting the .c files with a lot of ifde= f nests

I ran into = this while building a static wget-like downloader that would use an alterna= te hosts file to complement a custom local server that locally hosts some p= roblematic CDNs (to work around problems such as: waiting for ajax.googleap= is.com, platform.twitter.com etc...) but this is an obvious hack, not the t= ypical use case for a standard library... but then again part of the charm = of musl is its "hackability"


--- On Mon, 12/31/12, Rich Felker <da= lias@aerifal.cx> wrote:

From: Ri= ch Felker <dalias@aerifal.cx>
Subject: [musl] Agenda for next release?
T= o: musl@lists.openwall.com
Date: Monday, December 31, 2012, 2:11 PM
<= br>
Hi,

I don't have any immediate plan for = the next release, but I'd like to
start thinking about what we'd like to= go into it. A few things I know
are still pending that should be possib= le to include are:

- strverscmp
- zoneinfo
- inet_makeaddr
= - scanf %m modifier
- getifaddrs
- cpuset/affinity interfaces
- et= her.h interfaces

I know there's also interest in exposing sigreturn = and setcontext for
libunwind use, but it's difficult to do right and I'm= really skeptical
of the whole thing. Their use of sigreturn seems compl= etely incorrect
(and thus probably untested); sigreturn expects a struct= sigcontext on
the stack, not a pointer to a sigcontext in the first fun= ction
argument slot. I would rather have a conversation with their
developers first to determine if that code is even working/valid,= and
defer the corresponding additions to musl until we eventually add a= ll
the ucontext.h interfaces in working form.

Another port (perha= ps x32, like originally proposed) is also
definitely an option if anybod= y's up for doing it. I had considered
doing it myself in this release cy= cle, but I'm a bit busy with some
other projects for at least a couple w= eeks so I'd rather not get
bogged down in a big time-eater right away, a= nd instead spend my time
with musl on small isolated feature additions a= nd bug fixes.

Anything else I missed?

Rich
--1741458154-770386030-1356989859=:15084--