* [COFF] [TUHS] Tech Sq elevator [ really type-checking ] [not found] ` <202001130044.00D0ilcV616661@darkstar.fourwinds.com> @ 2020-01-13 0:49 ` wkt 0 siblings, 0 replies; 3+ messages in thread From: wkt @ 2020-01-13 0:49 UTC (permalink / raw) All, can we move this not-really-Unix discussion to COFF? Thanks, Warren P.S A bit more self-regulation too, please. You shouldn't need me to point out when the topic has drifted so far :-) ^ permalink raw reply [flat|nested] 3+ messages in thread
* [COFF] [TUHS] Tech Sq elevator [ really type-checking ] [not found] ` <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com> [not found] ` <202001130044.00D0ilcV616661@darkstar.fourwinds.com> @ 2020-01-13 1:23 ` crossd 2020-01-13 1:41 ` bakul 1 sibling, 1 reply; 3+ messages in thread From: crossd @ 2020-01-13 1:23 UTC (permalink / raw) -TUHS, +COFF, in line with Warren's wishes. On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah <bakul at bitblocks.com> wrote: > There is similar code in FreeBSD kernel. Embedding head and next ptrs > reduces > memory allocation and improves cache locality somewhat. Since C doesn't > have > generics, they try to gain the same functionality with macros. See > > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h > > Not that this is the same as what Linux does (which I haven't dug into) but > I suspect they may have had similar motivation. > I was actually going to say, "blame Berkeley." As I understand it, this code originated in BSD, and the Linux implementation is at least inspired by the BSD code. There was code for singly and doubly linked lists, queues, FIFOs, etc. I can actually understand the motivation: lists, etc, are all over the place in a number of kernels. The code to remove an element from a list is trivial, but also tedious and repetitive: if it can be wrapped up into a macro, why not do so? It's one less thing to mess up. I agree it's gone off the rails, however. - Dan C. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200112/b3fa8f64/attachment.html> ^ permalink raw reply [flat|nested] 3+ messages in thread
* [COFF] [TUHS] Tech Sq elevator [ really type-checking ] 2020-01-13 1:23 ` crossd @ 2020-01-13 1:41 ` bakul 0 siblings, 0 replies; 3+ messages in thread From: bakul @ 2020-01-13 1:41 UTC (permalink / raw) On Sun, 12 Jan 2020 20:23:11 -0500 Dan Cross <crossd at gmail.com> wrote: > > -TUHS, +COFF, in line with Warren's wishes. > > On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah <bakul at bitblocks.com> wrote: > > > There is similar code in FreeBSD kernel. Embedding head and next ptrs > > reduces > > memory allocation and improves cache locality somewhat. Since C doesn't > > have > > generics, they try to gain the same functionality with macros. See > > > > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h > > > > Not that this is the same as what Linux does (which I haven't dug into) but > > I suspect they may have had similar motivation. > > > > I was actually going to say, "blame Berkeley." As I understand it, this > code originated in BSD, and the Linux implementation is at least inspired > by the BSD code. There was code for singly and doubly linked lists, queues, > FIFOs, etc. > > I can actually understand the motivation: lists, etc, are all over the > place in a number of kernels. The code to remove an element from a list is > trivial, but also tedious and repetitive: if it can be wrapped up into a > macro, why not do so? It's one less thing to mess up. In late '90s when I first came across code in the FreebSD kernel, as a Scheme-phile I instinctively disliked it. But upon reflection and considering doing it the lisp way -- car,cdr, where car points to a data stucture, I realized this was better, The list way wouldn't have helped and made things worse. Now you may have to either cast the car (whose type would've been void*, which loses type safety) or define data structure specific types and you are back to needing lots of very similar functions. In addition you may now have to lock more data structures to manage these lists. Then consider what happens when an object is on multiple lists. Now you need O(n) operations to remove it from all the lists. And so on. > I agree it's gone off the rails, however. Well, this is "historic unix code" :-) ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-01-13 1:41 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU> [not found] ` <CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com> [not found] ` <202001122340.00CNeef0604557@darkstar.fourwinds.com> [not found] ` <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com> [not found] ` <202001130044.00D0ilcV616661@darkstar.fourwinds.com> 2020-01-13 0:49 ` [COFF] [TUHS] Tech Sq elevator [ really type-checking ] wkt 2020-01-13 1:23 ` crossd 2020-01-13 1:41 ` bakul
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).