Date: Mon, 11 Feb 2019 20:51:59 -0800 From: Jason Harmening <jason.harmening@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: FreeBSD Arch <freebsd-arch@freebsd.org> Subject: Re: Any desire for a more flexible bus_dmamem_alloc variant ? Message-ID: <CAM=8qamvXmGeSkXq8u1t9w3qR1cM_WYAd09TqHaTZoso=%2BSqzQ@mail.gmail.com> In-Reply-To: <7d214dbe-b873-e626-776a-efdf2ac693b7@FreeBSD.org> References: <ee0a8333-e5e8-0b4e-e5bd-7b1ad5410847@gmail.com> <7d214dbe-b873-e626-776a-efdf2ac693b7@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Feb 11, 2019 at 9:34 AM John Baldwin <jhb@freebsd.org> wrote: > On 2/10/19 1:13 AM, Jason Harmening wrote: > > I have this review I need to rebase and write the manpage bits for. While > it still ties the the size to the tag, it mostly hides the individual tag: > > https://reviews.freebsd.org/D5704 I like that. It doesn't fix my idealogical gripe about maxsize being a constraint vs. an allocation specifier. But I'm not sure that matters if it can get rid of most/all of the practical ramifications of the problem. Plus it kills off a bunch of other cruft too. Suggestion, maybe dumb: What if you added a flex array of segments at the end of struct bus_dmamem and a maxsegs argument in the args struct to allow multi-seg allocations? That would fix what might be the only real impediment to using this pretty much anywhere. > > > -- > John Baldwin > > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAM=8qamvXmGeSkXq8u1t9w3qR1cM_WYAd09TqHaTZoso=%2BSqzQ>