9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] wavelan config problems
Date: Tue, 17 Apr 2001 14:56:21 +0200	[thread overview]
Message-ID: <200104171256.OAA07614@polya.cs.utwente.nl> (raw)
In-Reply-To: Your message of "Thu, 12 Apr 2001 13:26:42 -0400." <20010412172644.9B85C199E9@mail.cse.psu.edu>

> On Thu Apr 12 09:18:24 EDT 2001, Axel.Belinfante@cs.utwente.nl wrote:
> > Oops. My debugging was erroneous: the failing w_cmd was _not_ for the
> > strings writing, but for cmd type 0xfc22 meaning WType_XClear.
> > For that request, in w_cmd the test (rc&WresSts) succeeds, causing it
> > to return failure.
> > What does this WresSts actually mean?
>
> You probably have as much information about the hardware as I do, we failed
> miserably to get any real documentation out of the Wavelan group.

I'm sorry to hear that.

> > Moreover, I had a second look at the strings writing in the linux driver.
[snip]
> > I.e. ltv.len is not taken from the sizeof the record, but takes
> > the variable length of the string into account, rounded up to even.
> > ltv.slen is just the length of the string.
>
> Here are the words from the HCF-Lite docs, clearly we're wrong in the
> setting of slen, but you tell me if the value of ltv.len is variable
> or not:
>
> 	10.1.3	cnfDesiredSSID
> 	Word Offset		Field name			Size (words)
> 	0				RecordLen: 18		1
> 	1				RID: FC02			1
> 	2				cnfDesiredSSID		17

Seems to be pretty fixed (non-variable). Seems I looked to much at the
linux driver, believing what I was reading there to be the truth...

> > The linux driver is full of htoas etc. translations
> > (the BUGS section of the plan9 driver mentions need for endian checks).
> > The linux driver allocates WNameLen+1 sized name buffers
> > in its Ctrl struct (instead of WNameLen, which we do).
>
> After looking at the above problems I'm going to go over the driver again
> and try to weed out some of the endian issues before they come back to bite
> us. I note, for instance, that the definition of the Wltv struct will not
> work on an alpha (not that I can try that as our only alpha died last week).

I'm glad to hear that (you going over the driver, not the alpha dying).

> If we didn't use the stuff we write, we'd never find out how many bugs
> it has. Thanks for taking the time to work over it.

You are more than welcome - it is the least (and right now, probably the
only thing) I can do to give something back.

Axel.



  reply	other threads:[~2001-04-17 12:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-12 17:26 jmk
2001-04-17 12:56 ` Axel Belinfante [this message]
  -- strict thread matches above, loose matches on Subject: below --
2001-04-17  7:29 nemo
2001-04-17  8:35 ` Axel Belinfante
2001-04-17  7:17 nemo
2001-04-11 20:47 jmk
2001-04-12 13:17 ` Axel Belinfante
2001-04-10 15:58 jmk
2001-04-11 14:37 ` Axel Belinfante
2001-04-10 15:31 Axel Belinfante

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200104171256.OAA07614@polya.cs.utwente.nl \
    --to=axel.belinfante@cs.utwente.nl \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).