From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14933 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Petr Vorel Newsgroups: gmane.linux.lib.musl.general Subject: Re: [RFC] fanotify_event_info_fid incompatibility Date: Tue, 12 Nov 2019 21:58:31 +0100 Message-ID: <20191112205831.GA27331@x230> References: <20191112200520.GA13138@x230> <20191112204619.GI25646@port70.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="101402"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.12.2 (2019-09-21) To: musl@lists.openwall.com, Rich Felker , Szabolcs Nagy Original-X-From: musl-return-14949-gllmg-musl=m.gmane.org@lists.openwall.com Tue Nov 12 21:58:48 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1iUdFQ-000QFV-Mc for gllmg-musl@m.gmane.org; Tue, 12 Nov 2019 21:58:48 +0100 Original-Received: (qmail 9928 invoked by uid 550); 12 Nov 2019 20:58:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9904 invoked from network); 12 Nov 2019 20:58:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=g+n3khGZ7dILcZvTNFTV6b+hg3EMZyi+zJVRKGPZtm8=; b=NPVBYNqU3huLYjTNW12VqWUSbKdy1eX52Ps/LANvTLpGoEBOrghnL6DlOu7olj0ehT jt1AldvCnx4WxyEIb+iywJ9ZcM1GDmngWL4XqkPaFVMPkQjPshpKVr2MKf/KtF3p31vQ WGG9r6h25JYCkIs7R7zXqr/HVOJhlNBsXpf9rczKGtKWxzR0ZxcrCdI+poSmvAL2WUOz bYlUakl7zHBwYfDQ3LhZTNVvgaGt3Lq6+YCG4W91sXP/hZZErOI9O0GIb+wnNN+2b1qR 4vklacCbs7ZD02nDDkxqPWJkDZacKSVB55E1MSzmFty0piWrELKbta+vgXm0iqRuIDoR uzMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=g+n3khGZ7dILcZvTNFTV6b+hg3EMZyi+zJVRKGPZtm8=; b=uGhzqOQP6uJ71Z9zlFjHzkrdyD+oRBsE+Tq/A1pASo0FjhnTfku7Lec1zOGHXqdm2z 8YUAk86XEAaqh36amcUDjCDpkDB+/o/e47EaUcaMuBJpN06KHWXfvLqbOk7fYEP6GlOm 4e0MOQQ3Tl+NCWz+M0q7Vgw4r3uQLoXG1SEvw0PwqnCV2rm1EVXf4lGXcTfsm+4/rWbx uCf0zk9iE2Z0N7Kx/lTZkatwyJ7Wa93Ewd/+0vavFqIEFmShmMylIDGgB6yl0KlgMzaj UXHBMoWgvhYmx5zOuGuvi4zQvv0DIQkS4AzfEUxAd6byNlsHdV16Co9vv/xsSkKiNx+k br9w== X-Gm-Message-State: APjAAAXm5E4RLVqsAHEPEbhBUwNgCUPoYaIVa7OzG3ziS1A+aD6t9W2k hjidPnYQ9DDKLELb+uQsUDnrkulo X-Google-Smtp-Source: APXvYqyYX3t1YdsxhFSmws4ayC+t8VnYQvIjBN3V0ZWt6g8AOPOEOk3jn/tsMznJtzTKDzH4KaFa5Q== X-Received: by 2002:adf:e8ce:: with SMTP id k14mr26521306wrn.393.1573592313968; Tue, 12 Nov 2019 12:58:33 -0800 (PST) Content-Disposition: inline In-Reply-To: <20191112204619.GI25646@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:14933 Archived-At: Hi, > * Petr Vorel [2019-11-12 21:05:20 +0100]: > > musl defines struct fanotify_event_info_fid member fsid as fsid_t. This > > conflicts with version from Linux kernel, which defines it as __kernel_fsid_t > > (musl's fsid_t has int __val[2], kernel's __kernel_fsid_t has int val[2]). > > I see commit 32b82cf5 ("fix the fsid_t structure to match name of __val"), > > which looks correct to me. > > I also think it's wrong, that other libc (at least glibc, uclibc-ng, bionic) > > don't define fanotify_event_info_fid and other structs thus users are forced to > > use definition from . But can be something done with this > > incompatibility? > yeah, glibc sys/fanotify.h just includes linux/fanotify.h > which uses linux types instead of libc ones, this is a > common pattern and there is no clean solution if users > rely on that > in such cases i try to keep updating sys/foo.h following > linux/foo.h changes, but in musl i try to use libc types > (e.g. if a field is __u64 then passing a pointer to it as > uint64_t* may not be valid so the glibc way is quite > problematic) Although I understand a reasons for using fsid_t instead of __kernel_fsid_t (and generally the approach of updating sys/foo.h), I still think that trying to define a kernel structure in libc but using different members isn't really user friendly :(. > glibc fsid_t uses __val but the __kernel_fsid_t has val, > musl could use a different type instead of fsid_t for > fanotify that has __val, but it's a bit ugly, is there a > reason to access fsid_t.val? LTP fanotify tests access it. Understand, that LTP is not typical user-space application (+ we can handle it either with autotools detection or just use instead of ). Kind regards, Petr [1] https://github.com/linux-test-project/ltp/tree/master/testcases/kernel/syscalls/fanotify