Dave Taht wrote: > I'm *really* impressed by the level of tool support emerging for ebpf, > but it's still essentially writing assembly when I'd rather use an > equivalent of bison or peg. If taking that massive step backwards is > the right thing, to build that tool (if none exists)... well... ok. years ago, I worked in the NPU space, and we created the language that I think you wanted. It was described here: https://www.ietf.org/archive/id/draft-nossik-pax-pdl-00.txt IPv4 patterns filters looked like this: PATTERN IP_v4_Hdr_For_ICMP { version UINT 4 == 4; ihl UINT 4 == 5; /* length == 5 : no options */ typeOfService UINT 8; totalLength UINT 16; identification UINT 16; flagReserved BIT 1 == 0; flagDontFragment BIT 1; flagMoreFragments BIT 1 == 0; /* last fragments only */ fragmentOffset UINT 13 == 0; /* first fragments only */ timeToLive UINT 8; protocol BIT 8 == IPPROTO_ICMP; /* ICMP */ headerChecksum BIT 16; sourceAddress BIT 32; destinationAddress BIT 32 } You could compile the patterns, and then instantiate fields at runtime if you needed to. (i.e: add constraints). Also merge patterns to select (a) or (b) in constant time (but not constant memory usage) Solidum (for whom I worked at the time) had a compiler that would turn this into ) patricia-tree filters that ran in hardware at wirespeed. But, APIs into ernels were hard to get accepted. In the end, only people willing to pay for this were TLAs who wanted to run regex's on traffic. Regex took lots of ram, but TLAs didn't buy many sockets. I would love to be able to recycle the compiler as open source; it could easily spit out EBPF, but generating assembly directly might be faster actually. The Patricia tree is basically jmp base+nextbyteofpacket., but stored more compactly. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [