netdev - Re: [PATCH for-next] net: provide __sys_shutdown

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <0b165669-c08e-3b12-6b78-197e782e5c00@kernel.dk>
Date:   Mon, 7 Sep 2020 13:32:56 -0600
From:   Jens Axboe <axboe@...nel.dk>
To:     Christoph Hellwig <hch@...radead.org>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     Networking <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH for-next] net: provide __sys_shutdown_sock() that takes a
 socket

On 9/7/20 11:00 AM, Christoph Hellwig wrote:
> On Mon, Sep 07, 2020 at 09:58:13AM -0700, Jakub Kicinski wrote:
>> On Mon, 7 Sep 2020 10:45:00 -0600 Jens Axboe wrote:
>>> On 9/6/20 11:48 PM, Christoph Hellwig wrote:
>>>> On Sat, Sep 05, 2020 at 04:05:48PM -0600, Jens Axboe wrote:  
>>>>> There's a trivial io_uring patch that depends on this one. If this one
>>>>> is acceptable to you, I'd like to queue it up in the io_uring branch for
>>>>> 5.10.  
>>>>
>>>> Can you give it a better name?  These __ names re just horrible.
>>>> sock_shutdown_sock?  
>>>
>>> Sure, I don't really care, just following what is mostly done already. And
>>> it is meant to be internal in the sense that it's not exported to modules.
>>>
>>> I'll let the net guys pass the final judgement on that, I'm obviously fine
>>> with anything in terms of naming :-)
>>
>> So am I :) But if Christoph prefers sock_shutdown_sock() let's use that.
> 
> Let's go with the original naming.  I might eventually do a big
> naming sweep in socket.c after cleaning up more of the compat mess.

Agree, saves me the hassle... FWIW, networking does have an even broader
space of func to __func to ____func and in some cases not "following" the
usual calling order of them.

-- 
Jens Axboe