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>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010226003319.A19994>