eeh@netbsd.org writes:
> Wow!  Someone actually read this!

Sorry to ... disappoint?  8-)


> 	> int
> 	> cn_isconsole(dev_t dev);
> 
> This is used by cn_check_magic().

yes, i got that later -- I guess I'm wondering is, why is it valuable
to push this abstraction out of the individual drivers, into common
macros.

I'm not sure what that adds; all i see is a forced (or hard to
override in a driver specific way) check of a global variable, when a
check of a local flags word already in cache or a register might
suffice.


> 	typically code for drivers which are capable of being the console also
> 	keep a flag around to note that fact.  I'd think that accessing a
> 	global (via a macro) to test this fairly often would be a lose --
> 	esp. if the alternative is checking a flag in a flags word defined in
> 	the softc, that may be needed for other work anyway.
> 
> It defaults to comparing the `dev' to the value of `cn_tab->cn_dev' but
> you can override it to do anything you want.

well... each driver could individually clobber it to look in their own
softc struct... but that only happens to work if there's a device
softc ptr in scope with a given name, etc...

I'm just not sure what the value of providing a generic macro to do
this _is_!  8-)


> 	> kern.cnmagic sysctl variable will be added.  This takes a
> 	> string.  cn_set_magic() will be used to convert kern.cnmagic to an internal
> 	> representation.
> 
> 	is there any reason to skimp on letters, in the user-visible name
> 	here?  to me, it unnecessarily obscures the usage of the variable.
> 
> O.K.  Name suggestions?

console_magic would be better.  I'm ... not so good at naming things.



> 	If i understand what you're proposing properly, it's kind of annoying
> 	for users who want to use BREAK to have to set it using ESC C-A...  i
> 	mean, that's probably the most common value desired (since it's the
> 	current default), and it seems a shame to make it ... quite so weird.
> 
> The encoding was quite arbitrary.  Since we could use any of 
> the 255 byte values as well as some values that are not part
> of the character stream, something needs to be escaped.  This
> seemed to be the simplest method.  Things get much nastier when
> you're using a keyboard, because the values tested are keycodes
> not ASCII.  For instance, `L1-A' becomes "\01\115".
> 
> I had originally planned to be able to set the magic sequence
> to a regular expression so you can define it for a set of different
> devices all at the same time.  However, this quickly became complex
> so I decided to go with a simpler solution for the time being.  

that seems kind-of insane...  (also, needs regexp code in the kernel.
8-)


> I'm not particularly married to this implementation, but trying
> to use regular expressions to match binary input streams is...
> interesting.

Right, so, i was thinking something more like a way to make the
representation for literal strings slightly different than that for
'special' characters.  I dunno...  Maybe something like:

	"string with \-escapes processed"
	BREAK (or break)

so:

	"foo\0bar"	-> foo<ESC><STX>bar (matching foo<NUL>bar in
			   input)
	"foo\"bar"	-> foo"bar
	BREAK		-> line break

i.e. don't treat it as a literal char.

Of course, if you then want to try to do things like:

	foo<BREAK>bar

you lose...

I dunno.  It's a problem that can be solved using documentation, but
the further you get from intuitive behaviour the more annoying it is,
in my opinion...  (of course, everybody's got a different definition
of intuitive.)


chris