From owner-freebsd-arch  Sun Feb 25 23:33:24 2001
Delivered-To: freebsd-arch@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 6903637B401
	for <arch@FreeBSD.org>; Sun, 25 Feb 2001 23:33:20 -0800 (PST)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id AAA20344
	for arch@FreeBSD.org; Mon, 26 Feb 2001 00:33:19 -0700 (MST)
	(envelope-from ken)
Date: Mon, 26 Feb 2001 00:33:19 -0700
From: "Kenneth D. Merry" <ken@kdm.org>
To: arch@FreeBSD.org
Subject: sbufs in userland
Message-ID: <20010226003319.A19994@panzer.kdm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


As part of a re-write of the CAM error recovery code that Justin and I have
been working on, I have been re-doing the CAM error printing code.

One of the things I'm working on is making the error printing code in the
kernel and in userland as similar as possible.

I would like to use the sbuf(9) interface to do the string formatting,
since it is fairly superior to my current string formatting method (see
scsi_sense_string() in sys/cam/scsi/scsi_all.c).

The problem is that the sbuf(9) code is kernel-only at the moment.  So this
brings up two basic questions:

1.	Should we put sbufs in userland?

	- At least for my purposes, I think this is a good idea.  For an
	  example of the code with and without sbufs, see the snippets
	  below from scsi_sense_string().

	- I've already done the minimal work necessary to make sbufs
	  compile and run in userland, so that isn't an issue.

	- I've mentioned this to DES (sbuf author), and he thinks it would
	  be a good idea to have sbufs available in userland.

2.	If we do put sbufs in userland, what is the best way to do it?
	There are three different ways I can think of:

		- Put sbufs in some existing library, or in a specially
		  created library, i.e. "libsbuf" or something like that.

		  The disadvantage to this from my perspective is that
		  we'll have to change the build process for all third
		  party applications that use libcam.  Those include
		  cdrecord, cdda2wav, tosha, SANE, xmcd, and who knows what
		  else.  They'll have to have some conditional make rule
		  to figure out whether to add libsbuf or libfoo.

		  It would probably be easier if sbufs were put in some
		  new library, so the makefiles could check for the
		  existence of libsbuf, and then add that to the link
		  line.  (Instead of checking the OS version.)

		- Put sbufs in libc.

		  This has the advantage, from my perspective, that
		  third-party applications wouldn't need any changes to
		  build with libcam after the change.

		  This has the distinct disadvantage of likely being
		  contraversial, and would perhaps violate some standard or
		  other for libc interfaces.

		- Put the code in libcam, and just don't advertise it.
		  It'll be used for the CAM functions, but no one will
		  know about it.

		  One advantage to this approach is that it wouldn't break
		  existing third-party applications that use libcam.

		  It wouldn't create an additional "supported" interface,
		  since it wouldn't be documented.

		  This is the approach I would prefer, since it wouldn't be
		  as contraversial as putting it in libc, and wouldn't
		  require changes to third party applications.

So, what color should this bike shed be?

Code without sbufs:

	switch (error_code) {
	case SSD_DEFERRED_ERROR:
		retlen = snprintf(tmpstr, tmpstrlen, "Deferred Error: ");

		if ((tmplen = str_len - cur_len - 1) < 0)
			goto sst_bailout;

		strncat(str, tmpstr, tmplen);
		cur_len += retlen;
		str[str_len - 1] = '\0';
		/* FALLTHROUGH */

Code with sbufs:

	switch (error_code) {
	case SSD_DEFERRED_ERROR:
		sbuf_printf(sb, "Deferred Error: ");

		/* FALLTHROUGH */

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message