From nobody Mon Jul 17 18:02:13 2023 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4R4VKN206Zz4nhCM; Mon, 17 Jul 2023 18:02:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4R4VKN1W3cz3G3W; Mon, 17 Jul 2023 18:02:16 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689616936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dGzdUZ967JcQnT7c+KJ5BUBH0fRYSUH8F2RtydIbrw4=; b=Mj//PGfEvrNCS+vRPnHz3Bog9YpXBtCSdQrgyPBSStqHaFEkEMGEVovVdJOwiWGgB5/MlE WatvduQR4FAvUUP9D18kk7de2FROS265bELORZL0C5UildkFCby3k/8edz4a2J237rRXzo 0UCC8nfFa91jt9ibByeS7KvUkb2pJrTz84JaIPy4OxxjU2B//IZG4Ub6fmG3PEx87kgvTu QFnYMVvB21S8JXuozRYlTy+qOqlhK7FbCyYLSo4eNpMOugasoOQkql1k3m0nnysMDqAG0Q v8bnq20of05aFh/phrexbwa+s8g4nNKxkj84dzKhqFqikCV4y8xvYbEHab9d+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1689616936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dGzdUZ967JcQnT7c+KJ5BUBH0fRYSUH8F2RtydIbrw4=; b=VWFWy04o7+6pFOMhCSktETECCXFtpdjGul14lbo4Lgccovo1FVUq+pNM+asSTexv0hBwaF yZ6W/BBhBxvLppelmAynBfk2SfrXklNQWWEBAkxDuuEbl0nG2IF4+g/dCTai8Jv+tVQMLz l/YcgCxElHuMHwQIFM3jqSHcpRDGJ5w+CR/E5DOk/R80ZcKQHe4cqEPilEl3Yqyb5v1PTF jX8w/fnbxhU+rbvBBhJq7WdIe3FN9DvIC2NORqVzB5FrY8upwV6s4xC3/i4f9sexACfjol FJScGd/eg1ETRfu8J6b/1jaL3di70awzvHRtscIv9DsAD576V5K+9AaXGy/VkQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1689616936; a=rsa-sha256; cv=none; b=kDmMOkOJJ0Tqd8zh/5S6XW+SH1epr0531lKMVYlOkSyAR/PPUeJ3ZxE6pC2o7DArkqEIe2 ZXijRD6YTz0WlLkeuJfH3A9bp0JurV+Oxb/+gbtESauno/gKrdA0s0QrIZgGpf0dn6lPjp h94wT8SCxfoDDvEyDUSyuW+M2ncEAx9QbGHWv2Dte6IDXtnC+pZY/HlBXnlnOt5IhLwjlO yBIP3ZMINYPD4CQ0UH9bqGsTNJBYuGTnHSazfE3UhM1jrllEIbThRpB1z4EHHWrqe40d03 xBfv8GdRbGga8BHv7ECMRPwOuyIJNd22QY/4sdE6ZbM2Nla3A0QO4eo9/miDnQ== Received: from [IPV6:2601:648:8680:16b0:2c33:b8f1:d09:3750] (unknown [IPv6:2601:648:8680:16b0:2c33:b8f1:d09:3750]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4R4VKM1hzdz1NRH; Mon, 17 Jul 2023 18:02:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <92656b28-8bfa-23a9-2683-23ccb817b8a7@FreeBSD.org> Date: Mon, 17 Jul 2023 11:02:13 -0700 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB. Content-Language: en-US To: Warner Losh , Konstantin Belousov Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org References: <202307141841.36EIf3f0019403@gitrepo.freebsd.org> <65d7d8d8-9f98-abd2-1ce3-ae3a2d3bf111@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 7/17/23 10:58 AM, Warner Losh wrote: > On Mon, Jul 17, 2023 at 11:54 AM Konstantin Belousov > wrote: > >> On Mon, Jul 17, 2023 at 11:29:20AM -0600, Warner Losh wrote: >>> On Mon, Jul 17, 2023 at 11:15 AM John Baldwin wrote: >>> >>>> On 7/17/23 8:48 AM, Konstantin Belousov wrote: >>>>> On Fri, Jul 14, 2023 at 06:41:03PM +0000, John Baldwin wrote: >>>>>> The branch main has been updated by jhb: >>>>>> >>>>>> URL: >>>> >> https://cgit.FreeBSD.org/src/commit/?id=60381fd1ee8668ea1e4676a6128883d987cab858 >>>>>> >>>>>> commit 60381fd1ee8668ea1e4676a6128883d987cab858 >>>>>> Author: John Baldwin >>>>>> AuthorDate: 2023-07-14 18:30:31 +0000 >>>>>> Commit: John Baldwin >>>>>> CommitDate: 2023-07-14 18:32:16 +0000 >>>>>> >>>>>> memdesc: Retire MEMDESC_CCB. >>>>>> >>>>>> Instead, change memdesc_ccb to examine the CCB and return a >>>> memdesc of >>>>>> a more generic type describing the data buffer. >>>>> >>>>>> diff --git a/sys/kern/subr_bus_dma.c b/sys/kern/subr_bus_dma.c >>>>>> index 65a08aeba17c..bfaad30b37d3 100644 >>>>>> --- a/sys/kern/subr_bus_dma.c >>>>>> +++ b/sys/kern/subr_bus_dma.c >>>>>> @@ -304,94 +304,6 @@ bus_dmamap_load_ma_triv(bus_dma_tag_t dmat, >>>> bus_dmamap_t map, >>>>>> @@ -566,49 +478,18 @@ bus_dmamap_load_ccb(bus_dma_tag_t dmat, >>>> bus_dmamap_t map, union ccb *ccb, >>>>>> + mem = memdesc_ccb(ccb); >>>>>> + return (bus_dmamap_load_mem(dmat, map, &mem, callback, >>>> callback_arg, >>>>>> + flags)); >>>>>> } >>>>> This makes kernel not linkable if CAM is not included into it. >>>> >>>> Hmmm, ok. I can either move the memdesc_ccb routine into sys/kern >>>> somewhere >>>> (like the kern_memdesc.c file in my other pending review), or we can >> #ifdef >>>> this function. It probably doesn't make sense to have a >>>> bus_dmamap_load_ccb >>>> if you don't have CAM, so I think I prefer the second option. >>>> >>> >>> MINIMAL doesn't have CAM configured, but it is loadable as a module. >>> >>> I'd think we'd want a dummy one fo these with weak symbol binding and >> have >>> the actual >>> one live in cam somewhere that overrides this symbol. >> The symbol resolution does not work this way in kernel. And it cannot >> made working this way even in theory, because cam.ko is loadable at >> runtime. >> > > Yea... It could, if we have perfect knowledge of all the places that it is > called. > But I don't think we do, now that I think about it... so yes, it's good to > want things, > but in this case my desire cannot exist, I agree. > > >> I believe the only feasible solution is to move memdesc_ccb() into kernel >> unconditionally. >> > > Or if it was in cam.h and made a static inline. It's short enough that > won't bloat > the kernel in the half a dozen places its called, and it would give similar > performance > to what we have today with the half a dozen nearly identical copies of > this routine. > And since it's all done with structure dancing, there's no other bits of > CAM that would > be brought into the kernel. I would be happy with an inline actually, I wasn't sure originally if that was too invasive in terms of the header bloat it would entail, in particular if it lived in sys/memdesc.h, but maybe it could live in cam_ccb.h? -- John Baldwin