Extension to Samba IDL.

Christopher R. Hertel crh at nts.umn.edu
Mon Jun 19 17:35:15 GMT 2000


On Jun 20,  2:25am, Elrond wrote:
> Subject: Re: Extension to Samba IDL.
>
> Hehe... When I talked with Matty and Luke about extensions,
> everyone told me, that those are a bad idea, and everyone
> told me, it's always better to keep with msidl on that...
> After a while, I saw, that most stuff could be done with it
> (and other could be done with some tricky attributes, I
> learned later about)

That's why I asked before making this extension.  The other thing I'm working
on is finding a way to add yodl to comment blocks so that we can generate
documentation from the same source files.  That shouldn't break anything in
MIDL unless MS get the same idea but require the use of MS-WORD or somesuch.

> hehe... and now everybody is pro samba-specific
> extensions...

I think it's specific to this extension, which is similar to bitfields in C
anyway.

> Okay, some comments follow:
>
> On Sat, Jun 17, 2000 at 07:59:29AM +1000, Christopher R. Hertel wrote:
> > All I need is the go-ahead on what I proposed.
>
> I've no probs with extensions, I wanted some too. And got
> told, it's a bad idea... after some long discussion, I got
> a little pissed and just stopped the discussion and went
> doing other stuff. ;)

Can you write them up for us again?  I'd be interested to know what you had in
mind.

> > Some quick notes:
> >
> > 1) When using bitfields, we will have to be careful with alignment.  A two
> >    bit field with no following padding or alignment specified will shift
> >    the rest of the packet.  By default, I think that we should force any
> >    non-bitfield value to start on a byte boundary.
>
> Yep. Having bytes and other stuff not even aligned at 8 bit
> will make samba extremely slow... So I think, this is the
> right way: Aligning non-bitfields at a minimum of 8 bit...

It's more a question of how the bytes are alligned in the off-the-wire
packet.  In most cases byte fields and larger will be aligned.  I have
read of some bit-oriented protocols that don't align things on byte
boundaries but I don't think we have to worry about that.

> If you realy need a byte, that is not aligned properly, you
> should do uint8:8 or somesuch.

Yes, something like that.  I'm thinking:

- Byte alignment is the current default anyway, since there are no
  bitfields implemented.  Also, byte alignment is *not* the same as
  alignment specified by 'option autoalign'.

- Any non-bit fields (ints, uints, etc.) would be byte aligned by
  default.  That is, nothing changes for these.  Bit fields (int:x,
  uint:x) would *not* be byte-aligned by default.  In many cases, the
  bitfield is going to follow a byte-aligned value anyway, meaning that
  it will start on a byte boundary.  The only time that non-aligned
  bitfields will make a difference is a bitfield following a bitfield
  (as in NetBIOS Name example).

  So, if you have:

  [x|x][-|-|-|-|-|-][y|y|y|y|y|y][+|+][uint8]

  where xx is a two-bit field, dashes are cruft, and yyyyyy is a 6-bit
  field ++ are more cruft, and [uint8] is an actuall byte...

  ...then you'd either have to declare padding for the dashed space
  or we need an 'option bitfield align' (or some directive in the IDL
  code).  The ++ space doesn't need padding since the uint8 will be
  aligned.

  My preference is to leave out any directives or options and use
  padding bits in the very rare cases it's necessary.  It certainly
  seems the simplest solution and doesn't clutter the language.

  BTW, when specifying a bitfield using the [u]int:x syntax, the parsed
  data can be read into byte, short, or long depending on the value of
  x.   If x <= 8 then use a byte, x <=16 use a short, etc.

> > 2) It's not good enough to simply mask a byte or word.  In the example I
> >    gave, you either have:
> >
> >    [x|x|y|y|y|y|y|y] or
> >    [x|x|z|z|z|z|z|z|z|z|z|z|z|z|z|z] depending on the value of xx.
> >
> >    So, if you parse it as a uint8 it might turn out that you needed a
> >    uint16, and vice versa.
>
> Hmm... that's a run-time issue... not easy, but it should
> be doable.

Easier to do in the IDL code (if it's supported).

Chris -)-----

-- 
Christopher R. Hertel -)-----                   University of Minnesota
crh at nts.umn.edu              Networking and Telecommunications Services


More information about the samba-technical mailing list