Date: Mon, 17 Jul 2023 11:52:07 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: 60381fd1ee86 - main - memdesc: Retire MEMDESC_CCB. Message-ID: <CANCZdfrr3pPhkbueJyHLYA0FhkKXQefSNx=QLOUjxNPh4FR1Aw@mail.gmail.com> In-Reply-To: <17cd00bb-c6f2-5afa-a1ac-b7e14c3c758e@FreeBSD.org> References: <202307141841.36EIf3f0019403@gitrepo.freebsd.org> <ZLVizUl1Xyo1AQmy@kib.kiev.ua> <65d7d8d8-9f98-abd2-1ce3-ae3a2d3bf111@FreeBSD.org> <CANCZdfoHid=H1Ys_4XTJPfCaifevSoW92nGYXU3Ot=mTT13T%2Bg@mail.gmail.com> <17cd00bb-c6f2-5afa-a1ac-b7e14c3c758e@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Mon, Jul 17, 2023 at 11:45 AM John Baldwin <jhb@freebsd.org> wrote: > On 7/17/23 10:29 AM, Warner Losh wrote: > > On Mon, Jul 17, 2023 at 11:15 AM John Baldwin <jhb@freebsd.org> 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 <jhb@FreeBSD.org> > >>>> AuthorDate: 2023-07-14 18:30:31 +0000 > >>>> Commit: John Baldwin <jhb@FreeBSD.org> > >>>> 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. > > > > I just hit this in building MINIMAL for other reasons.... > > Yeah, I was testing MINIMAL locally (which is still broken due to recent > TCP commits) to try out possible fixes. One could possibly move > bus_dmamap_load_ccb into cam.ko entirely? Especially this current version > doesn't really have any bus_dma-specific knowledge anymore but is just a > thin wrapper around bus_dmamap_load_mem: > > int > bus_dmamap_load_ccb(bus_dma_tag_t dmat, bus_dmamap_t map, union ccb *ccb, > bus_dmamap_callback_t *callback, void *callback_arg, > int flags) > { > struct ccb_hdr *ccb_h; > struct memdesc mem; > > ccb_h = &ccb->ccb_h; > if ((ccb_h->flags & CAM_DIR_MASK) == CAM_DIR_NONE) { > callback(callback_arg, NULL, 0, 0); > return (0); > } > > mem = memdesc_ccb(ccb); > return (bus_dmamap_load_mem(dmat, map, &mem, callback, > callback_arg, > flags)); > } > And who calls bus_dmamap_load_ccb? If this were entirely in cam.ko, then callers of it would need to resolve it. sys/dev/nvme/nvme_qpair.c is not otherwise dependent on cam, and would be unresolved for a minimal + nvme + nvd kernel. Warner [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 17, 2023 at 11:45 AM John Baldwin <<a href="mailto:jhb@freebsd.org">jhb@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 7/17/23 10:29 AM, Warner Losh wrote:<br> > On Mon, Jul 17, 2023 at 11:15 AM John Baldwin <<a href="mailto:jhb@freebsd.org" target="_blank">jhb@freebsd.org</a>> wrote:<br> > <br> >> On 7/17/23 8:48 AM, Konstantin Belousov wrote:<br> >>> On Fri, Jul 14, 2023 at 06:41:03PM +0000, John Baldwin wrote:<br> >>>> The branch main has been updated by jhb:<br> >>>><br> >>>> URL:<br> >> <a href="https://cgit.FreeBSD.org/src/commit/?id=60381fd1ee8668ea1e4676a6128883d987cab858" rel="noreferrer" target="_blank">https://cgit.FreeBSD.org/src/commit/?id=60381fd1ee8668ea1e4676a6128883d987cab858</a><br>; >>>><br> >>>> commit 60381fd1ee8668ea1e4676a6128883d987cab858<br> >>>> Author: John Baldwin <jhb@FreeBSD.org><br> >>>> AuthorDate: 2023-07-14 18:30:31 +0000<br> >>>> Commit: John Baldwin <jhb@FreeBSD.org><br> >>>> CommitDate: 2023-07-14 18:32:16 +0000<br> >>>><br> >>>> memdesc: Retire MEMDESC_CCB.<br> >>>><br> >>>> Instead, change memdesc_ccb to examine the CCB and return a<br> >> memdesc of<br> >>>> a more generic type describing the data buffer.<br> >>><br> >>>> diff --git a/sys/kern/subr_bus_dma.c b/sys/kern/subr_bus_dma.c<br> >>>> index 65a08aeba17c..bfaad30b37d3 100644<br> >>>> --- a/sys/kern/subr_bus_dma.c<br> >>>> +++ b/sys/kern/subr_bus_dma.c<br> >>>> @@ -304,94 +304,6 @@ bus_dmamap_load_ma_triv(bus_dma_tag_t dmat,<br> >> bus_dmamap_t map,<br> >>>> @@ -566,49 +478,18 @@ bus_dmamap_load_ccb(bus_dma_tag_t dmat,<br> >> bus_dmamap_t map, union ccb *ccb,<br> >>>> + mem = memdesc_ccb(ccb);<br> >>>> + return (bus_dmamap_load_mem(dmat, map, &mem, callback,<br> >> callback_arg,<br> >>>> + flags));<br> >>>> }<br> >>> This makes kernel not linkable if CAM is not included into it.<br> >><br> >> Hmmm, ok. I can either move the memdesc_ccb routine into sys/kern<br> >> somewhere<br> >> (like the kern_memdesc.c file in my other pending review), or we can #ifdef<br> >> this function. It probably doesn't make sense to have a<br> >> bus_dmamap_load_ccb<br> >> if you don't have CAM, so I think I prefer the second option.<br> >><br> > <br> > MINIMAL doesn't have CAM configured, but it is loadable as a module.<br> > <br> > I'd think we'd want a dummy one fo these with weak symbol binding and have<br> > the actual<br> > one live in cam somewhere that overrides this symbol.<br> > <br> > I just hit this in building MINIMAL for other reasons....<br> <br> Yeah, I was testing MINIMAL locally (which is still broken due to recent<br> TCP commits) to try out possible fixes. One could possibly move<br> bus_dmamap_load_ccb into cam.ko entirely? Especially this current version<br> doesn't really have any bus_dma-specific knowledge anymore but is just a<br> thin wrapper around bus_dmamap_load_mem:<br> <br> int<br> bus_dmamap_load_ccb(bus_dma_tag_t dmat, bus_dmamap_t map, union ccb *ccb,<br> bus_dmamap_callback_t *callback, void *callback_arg,<br> int flags)<br> {<br> struct ccb_hdr *ccb_h;<br> struct memdesc mem;<br> <br> ccb_h = &ccb->ccb_h;<br> if ((ccb_h->flags & CAM_DIR_MASK) == CAM_DIR_NONE) {<br> callback(callback_arg, NULL, 0, 0);<br> return (0);<br> }<br> <br> mem = memdesc_ccb(ccb);<br> return (bus_dmamap_load_mem(dmat, map, &mem, callback, callback_arg,<br> flags));<br> }<br></blockquote><div><br></div><div>And who calls bus_dmamap_load_ccb? If this were entirely in cam.ko, then callers of it would<br></div><div>need to resolve it. sys/dev/nvme/nvme_qpair.c is not otherwise dependent on cam, and would</div><div>be unresolved for a minimal + nvme + nvd kernel.</div><div><br></div><div>Warner</div></div></div>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrr3pPhkbueJyHLYA0FhkKXQefSNx=QLOUjxNPh4FR1Aw>