Nabble - freebsd-hackers

Converting a bootable USB stick in to bootable CD-ROM

2009-11-10T15:14:02Z

I posted this on the -questions list but didn't get any replies. I have a FreeBSD image that I install on USB sticks to build new systems. When the stick boots it automatically clones itself on the system's hard drive, creating partitions and other configuration parameters that are programmed into the stick's cloning logic. I want to create a similar mechanism using a bootable CD-ROM. The biggest difference in the process of course is that the CD-ROM itself is read-only so clearly there needs to be an mfsroot involved in the process. I looked at how the FreeBSD Live CD is setup and the loader.conf file has these lines:

mfsroot_load="YES"

mfsroot_type="mfs_root"

mfsroot_name="/boot/mfsroot"

along with the file /boot/mfsroot.gz and no /etc/fstab. The fstab on my USB stick version has root mounted as /etc/da0s1a and clearly that isn't going to work. I changed my core BSD image accordingly, duplicating the mfsroot settings in my loader.conf.

I used the command below to create the iso file from the BSD image I prepared.

mkisofs -R -no-emul-boot -o /tmp/bsd.iso -b boot/cdboot /bsd

When this iso is copied to a CD, it does boot. However, it doesn't seem to be picking up the mfsroot config and complains that the system is running from on a read-only file system, which of course is what I'm trying to avoid.

I assume I simply have the boot config setup wrong. I essentially want the same kind of thing that's done for BSD Live. Can anyone point me to the right info for setting up this kind of bootable BSD CD?

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Alps GlidePoint driver for synaptics.

2009-11-10T12:46:46Z

Hello there,

I noticed that for the moment there is no support for alps based
touchpads, is there anyone working on a driver for -CURRENT ? This is
my touchpad :

I: Bus=0011 Vendor=0002 Product=0008 Version=7321
N: Name="AlpsPS/2 ALPS GlidePoint"
P: Phys=isa0060/serio4/input0
S: Sysfs=/devices/platform/i8042/serio4/input/input6
U: Uniq=
H: Handlers=mouse2 event6
B: EV=f
B: KEY=420 0 70000 0 0 0 0 0 0 0 0
B: REL=3
B: ABS=1000003

Cheers,
David.
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T12:24:28Z

2009/11/10 Dag-Erling Smørgrav <des@...>:

> Alexander Best <alexbestms@...> writes:
>> you're right. hundreds of functions cause segfaults when arg or args
>> are NULL. either we add safety checks for all of them (massive
>> overhead) or just leave them the way they are.
>
> The consensus in the C community is that adding such checks does more
> harm than good, because a NULL pointer is usually a symptom of a bug
> somewhere else in the application, and checking for a NULL pointer will
> either hide that bug or trigger another error somewhere down the line,
> possibly making the real bug harder to find, rather than easier.
>

And which is a way some well known OS' developers like to choose to
fix sec.holes. No cookie.
P.S. I apologize for flaming on this.

> (next week's topic: the return value of malloc(0)...)
>
> DES
> --
> Dag-Erling Smørgrav - des@...

--
wbr,
pluknet
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T12:13:43Z

Alexander Best <alexbestms@...> writes:
> you're right. hundreds of functions cause segfaults when arg or args
> are NULL. either we add safety checks for all of them (massive
> overhead) or just leave them the way they are.

The consensus in the C community is that adding such checks does more
harm than good, because a NULL pointer is usually a symptom of a bug
somewhere else in the application, and checking for a NULL pointer will
either hide that bug or trigger another error somewhere down the line,
possibly making the real bug harder to find, rather than easier.

(next week's topic: the return value of malloc(0)...)

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T10:42:26Z

On Tue, 10 Nov 2009, Andriy Gapon wrote:

> on 10/11/2009 13:54 Andriy Gapon said the following:
>> on 09/11/2009 22:34 Gavin Atkinson said the following:
>>> Secondly, I get a panic on module unlaod. I haven't spent any time
>>> looking at this, if you haven't fixed it yet let me know and I'll look
>>> into it further.
>>
>> To my shame I still haven't got around to testing the driver with head tree and
>> diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
>> Robert Noland has reported that he had a lockup on module unload with head
>> sources. I will investigate this.
>> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
>> debugger reports it correctly). This looks like the memory was already freed.
>
> I think I've found one bug in the heci code that could cause this - SLIST element
> was first freed and then removed from the list.
> I've uploaded updated sources (that should include your PCI ID too), could you
> please re-test?

That seems to have fixed it, thanks! It also fixes the malloc() calls
with locks held.

> Could you please send me verbose version of driver attachment messages
> (debug.bootverbose=1)?
> Thank you!

Sure!

http://people.freebsd.org/~gavin/heci-verbose.txt

Gavin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T09:12:48Z

on 10/11/2009 13:54 Andriy Gapon said the following:

> on 09/11/2009 22:34 Gavin Atkinson said the following:
>> Secondly, I get a panic on module unlaod. I haven't spent any time
>> looking at this, if you haven't fixed it yet let me know and I'll look
>> into it further.
>
> To my shame I still haven't got around to testing the driver with head tree and
> diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
> Robert Noland has reported that he had a lockup on module unload with head
> sources. I will investigate this.
> BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
> debugger reports it correctly). This looks like the memory was already freed.

I think I've found one bug in the heci code that could cause this - SLIST element
was first freed and then removed from the list.
I've uploaded updated sources (that should include your PCI ID too), could you
please re-test?

>> I'm not even sure how it's getting that far into the detach routine
>> before panicing, if dev really does = 0xdeadc0dedeadc0de
>>
>> #8 0xffffffff808580d3 in calltrap ()
>> at /usr/src/sys/amd64/amd64/exception.S:224
>> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
>> at /usr/src/sys/kern/kern_mutex.c:827
>> #10 0xffffffff812221c6 in heci_detach ()
>> from /usr/src/sys/modules/heci/heci.ko
>> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
>> at device_if.h:212
>> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
>> what=Variable "what" is not available.
>> ) at /usr/src/sys/kern/subr_bus.c:1156
>> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
>> at /usr/src/sys/kern/kern_module.c:266
>> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
>> flags=0) at /usr/src/sys/kern/kern_linker.c:633
>> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
>> fileid=Variable "fileid" is not available.
>> ) at /usr/src/sys/kern/kern_linker.c:1092
>>
>> Let me know if there's anything else I can test.
>>
>> Thanks,
>
> Nothing else I can think of right now.

OK, I came up with something :)
Could you please send me verbose version of driver attachment messages
(debug.bootverbose=1)?
Thank you!

BTW, Robert, you also promised me those :)

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

RE: [patch] burncd: honour for envar SPEED

2009-11-10T09:12:30Z

> On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote:
> > On Tue, 10 Nov 2009, Alexander Best wrote:
> >
> > >ps: would be nice if strcasecmp could protect itself from segfault
> > >with one or both of the args being NULL.
> >
> > I disagree. What do you think it should do instead? Return 0? If
it
> > did, would you have found your bug?
> >
> > [snip]
>
> I remember System V to actually map zero page at 0, thus causing all
> string functions to behave like it was supplied empty string when
argument
> is NULL. I believe Solaris still provides the library that could be
> LD_PRELOADed for the same effect.

Just an anecdote:

My sophomore year of undergrad (1994), I was learning C for the first
time. We had to write some little thing, and on the machines in the lab
my C program ran great; I had debugged it (I thought) and turned it in.

The instructor took my source, compiled it on Linux, and it segfaulted
when run (I think trying to print a NULL string).

If HP-UX hadn't been trying to be "friendly" I would have been able to
fully debug my code. I am sure that if I'd known then what I know now I
could have made it bug free. But my experience is that a lot of code
is, by necessity, written by people who aren't experts in everything
they're doing.

So an early segfault would have helped me in that C programming class.
OTOH, if instead it had been an application someone paid money for, and
it segfaulted in an untested error case instead of being graceful, I'd
be mad too. Probably at the app writer, but still...

Cheers,
matthew
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T08:59:36Z

On Tue, Nov 10, 2009 at 08:03:26AM -0800, Nate Eldredge wrote:

> On Tue, 10 Nov 2009, Alexander Best wrote:
>
> >ps: would be nice if strcasecmp could protect itself from segfault with
> >one or
> >both of the args being NULL.
>
> I disagree. What do you think it should do instead? Return 0? If it
> did, would you have found your bug?
>
> The same argument could be made for any of the string.h functions, but I
> don't think it actually holds water. Such checks add overhead, and only
> provide an illusion of safety. Sure, strcasecmp could avoid causing the
> segfault itself, but at the cost of letting a broken program continue and
> possibly cause more damage. It could call abort(), but then you'd just
> have the same result (program terminates) with a different signal, and
> doing your check in software rather than letting the MMU hardware do it.
> It could print a message, but that pollutes the program's output, and 15
> seconds debugging the core dump will reveal the problem anyway.
>
> Having a library function "protect itself" in this manner is not actually
> helpful, IMHO.

I remember System V to actually map zero page at 0, thus causing
all string functions to behave like it was supplied empty string
when argument is NULL. I believe Solaris still provides the library
that could be LD_PRELOADed for the same effect.

attachment0 (203 bytes) Download Attachment

Re: [patch] burncd: honour for envar SPEED

2009-11-10T08:17:38Z

Nate Eldredge schrieb am 2009-11-10:
> On Tue, 10 Nov 2009, Alexander Best wrote:

> >ps: would be nice if strcasecmp could protect itself from segfault
> >with one or
> >both of the args being NULL.

> I disagree. What do you think it should do instead? Return 0? If
> it did, would you have found your bug?

> The same argument could be made for any of the string.h functions,
> but I don't think it actually holds water. Such checks add
> overhead, and only provide an illusion of safety. Sure, strcasecmp
> could avoid causing the segfault itself, but at the cost of letting
> a broken program continue and possibly cause more damage. It could
> call abort(), but then you'd just have the same result (program
> terminates) with a different signal, and doing your check in
> software rather than letting the MMU hardware do it. It could print
> a message, but that pollutes the program's output, and 15 seconds
> debugging the core dump will reveal the problem anyway.

> Having a library function "protect itself" in this manner is not
> actually helpful, IMHO.

> --

> Nate Eldredge
> nate@...

you're right. hundreds of functions cause segfaults when arg or args are NULL.
either we add safety checks for all of them (massive overhead) or just leave
them the way they are. also: these functions aren't being used by regular
users, but developers and it's hard finding a developer who isn't experienced
with dealing with NULL pointers. ;) so problems with NULL pointers are usually
fixed very quickly.

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T08:03:26Z

On Tue, 10 Nov 2009, Alexander Best wrote:

> ps: would be nice if strcasecmp could protect itself from segfault with one or
> both of the args being NULL.

I disagree. What do you think it should do instead? Return 0? If it
did, would you have found your bug?

The same argument could be made for any of the string.h functions, but I
don't think it actually holds water. Such checks add overhead, and only
provide an illusion of safety. Sure, strcasecmp could avoid causing the
segfault itself, but at the cost of letting a broken program continue and
possibly cause more damage. It could call abort(), but then you'd just
have the same result (program terminates) with a different signal, and
doing your check in software rather than letting the MMU hardware do it.
It could print a message, but that pollutes the program's output, and 15
seconds debugging the core dump will reveal the problem anyway.

Having a library function "protect itself" in this manner is not actually
helpful, IMHO.

--

Nate Eldredge
nate@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T07:50:07Z

Dag-Erling Smørgrav schrieb am 2009-11-10:
> Alexander Best <alexbestms@...> writes:
> > good point. is this one better?

> Yes (modulo indentation - run your code through tabify)

> DES

oops. found another problem. if BURNCD_SPEED and -s aren't defined strcasecmp
segfaults because env_speed is NULL.

does this patch take care of the problem?

alex

ps: would be nice if strcasecmp could protect itself from segfault with one or
both of the args being NULL.

Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199125)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -27,7 +27,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 2, 2005
+.Dd Nov 9, 2009
.Os
.Dt BURNCD 8
.Sh NAME
@@ -158,7 +158,11 @@
.Sh ENVIRONMENT
The following environment variables affect the execution of
.Nm :
-.Bl -tag -width ".Ev CDROM"
+.Bl -tag -width ".Ev BURNCD_SPEED"
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
.It Ev CDROM
The CD device to use if one is not specified with the
.Fl f
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199125)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,13 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ env_speed = getenv("BURNCD_SPEED");
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':
@@ -124,12 +126,7 @@
break;

case 's':
- if (strcasecmp("max", optarg) == 0)
- speed = CDR_MAX_SPEED;
- else
- speed = atoi(optarg) * 177;
- if (speed <= 0)
- errx(EX_USAGE, "Invalid speed: %s", optarg);
+ env_speed = optarg;
break;

case 't':
@@ -147,6 +144,15 @@
argc -= optind;
argv += optind;

+ if (env_speed == NULL)
+ ;
+ else if (strcasecmp("max", env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", optarg);
+
if (argc == 0)
usage();

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-10T03:54:09Z

on 09/11/2009 22:34 Gavin Atkinson said the following:

> On Wed, 14 Oct 2009, Andriy Gapon wrote:
>> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
>> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>>
>> I actually got around to implementing it (in initial/basic form):
>> http://people.freebsd.org/~avg/heci.tgz
>
> Nice!
>
> I've got the following device in my laptop:
>
> heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086
> rev=0x07 hdr=0x00
> vendor = 'Intel Corporation'
> device = 'Intel Management Engine Interface (Mobile 4 Series
> Chipset)'
> class = simple comms
>
> I've added this device to the code, and loaded it:
>
> heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem
> 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0

I will add this ID and name to the driver.

> heci0: using MSI
> heci0: [ITHREAD]
> heci0: found ME client at address 0x02:
> heci0: status = 0x00
> heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
> heci0: found ME client at address 0x06:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
> heci0: found ME client at address 0x07:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
> heci0: found ME client at address 0x20:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
> heci0: found ME client at address 0x21:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
> heci0: found ME client at address 0x22:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
> heci0: found ME client at address 0x23:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
> heci0: found ME client at address 0x24:
> heci0: status = 0x00
> heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

Thanks a lot for testing!

> However, running the heci-qst.c program you supplied:
>
> psi# ./heci-qst
> ioctl HECI_CONNECT: No such file or directory
>
> And output to the console:
>
> heci0: could not find ME client with given guid:
> 6B5205B9-8185-4519-B889-D98724B58607
>
> Other than seeing that it doesn't appear in the list above, I don't know
> if this is expected or not...

Yes, this is expected if you don't have ME client with this GUID.
Perhaps, there is no QST firmware in the ME or it is disabled. Also, I am not
sure but I think that it could be possible that you have a newer version of QST
and its GUID is different. If you feel adventurous, you could try substituting
GUID value in heci-qst.c with values reported by the driver. Perhaps it would
work, perhaps you'd get a crash or hang or just an ioctl error.

> Secondly, I get a panic on module unlaod. I haven't spent any time
> looking at this, if you haven't fixed it yet let me know and I'll look
> into it further.

To my shame I still haven't got around to testing the driver with head tree and
diagnostics enabled. I do not see any problems on stable/7 without diagnostics.
Robert Noland has reported that he had a lockup on module unload with head
sources. I will investigate this.
BTW, 0xdeadc0dedeadc0de as arg to device_detach() looks really strange (if
debugger reports it correctly). This looks like the memory was already freed.

> I'm not even sure how it's getting that far into the detach routine
> before panicing, if dev really does = 0xdeadc0dedeadc0de
>
> #8 0xffffffff808580d3 in calltrap ()
> at /usr/src/sys/amd64/amd64/exception.S:224
> #9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
> at /usr/src/sys/kern/kern_mutex.c:827
> #10 0xffffffff812221c6 in heci_detach ()
> from /usr/src/sys/modules/heci/heci.ko
> #11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
> at device_if.h:212
> #12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
> what=Variable "what" is not available.
> ) at /usr/src/sys/kern/subr_bus.c:1156
> #13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
> at /usr/src/sys/kern/kern_module.c:266
> #14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
> flags=0) at /usr/src/sys/kern/kern_linker.c:633
> #15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
> fileid=Variable "fileid" is not available.
> ) at /usr/src/sys/kern/kern_linker.c:1092
>
> Let me know if there's anything else I can test.
>
> Thanks,

Nothing else I can think of right now.
Thanks again!

--
Andriy Gapon
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-10T00:00:29Z

Alexander Best <alexbestms@...> writes:
> good point. is this one better?

Yes (modulo indentation - run your code through tabify)

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T13:11:25Z

Dag-Erling Smørgrav schrieb am 2009-11-09:
> Alexander Best <alexbestms@...> writes:

> > + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
> > + if (strcasecmp("max", env_speed) == 0)
> > + speed = CDR_MAX_SPEED;
> > + else
> > + speed = atoi(env_speed) * 177;
> > + if (speed <= 0)
> > + errx(EX_USAGE, "Invalid speed: %s",
> > env_speed);
> > + }
> > +
> > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> > switch (ch) {
> > case 'd':

> You realize you're duplicating 6 lines of non-trivial code for no
> good
> reason?

> env_speed = getenv("BURNCD_SPEED");

> while ((ch = getopt(...)) != -1) {
> switch (ch) {
> case 's':
> env_speed = optarg;
> break;
> ...
> }
> }

> if (env_speed != NULL) {
> if (strcasecmp...) {
> ...
> }
> }

> DES

good point. is this one better?

alex

Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199064)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -27,7 +27,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 2, 2005
+.Dd Nov 9, 2009
.Os
.Dt BURNCD 8
.Sh NAME
@@ -158,7 +158,11 @@
.Sh ENVIRONMENT
The following environment variables affect the execution of
.Nm :
-.Bl -tag -width ".Ev CDROM"
+.Bl -tag -width ".Ev BURNCD_SPEED"
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
.It Ev CDROM
The CD device to use if one is not specified with the
.Fl f
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,13 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ env_speed = getenv("BURNCD_SPEED");
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':
@@ -124,12 +126,7 @@
break;

case 's':
- if (strcasecmp("max", optarg) == 0)
- speed = CDR_MAX_SPEED;
- else
- speed = atoi(optarg) * 177;
- if (speed <= 0)
- errx(EX_USAGE, "Invalid speed: %s", optarg);
+ env_speed = optarg;
break;

case 't':
@@ -147,6 +144,13 @@
argc -= optind;
argv += optind;

+ if (strcasecmp("max", env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", optarg);
+
if (argc == 0)
usage();

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T12:58:21Z

Alexander Best <alexbestms@...> writes:

>
> + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
> + if (strcasecmp("max", env_speed) == 0)
> + speed = CDR_MAX_SPEED;
> + else
> + speed = atoi(env_speed) * 177;
> + if (speed <= 0)
> + errx(EX_USAGE, "Invalid speed: %s", env_speed);
> + }
> +
> while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> switch (ch) {
> case 'd':

You realize you're duplicating 6 lines of non-trivial code for no good
reason?

env_speed = getenv("BURNCD_SPEED");

while ((ch = getopt(...)) != -1) {
switch (ch) {
case 's':
env_speed = optarg;
break;
...
}
}

if (env_speed != NULL) {
if (strcasecmp...) {
...
}
}

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: heci: a new driver for review and testing

2009-11-09T12:34:09Z

On Wed, 14 Oct 2009, Andriy Gapon wrote:
> Some time ago I posted some ideas about HECI/MEI driver for FreeBSD:
> http://docs.freebsd.org/cgi/mid.cgi?4968E9A1.3080006
>
> I actually got around to implementing it (in initial/basic form):
> http://people.freebsd.org/~avg/heci.tgz

Nice!

I've got the following device in my laptop:

heci0@pci0:0:3:0: class=0x078000 card=0x00011179 chip=0x2a448086 rev=0x07 hdr=0x00
vendor = 'Intel Corporation'
device = 'Intel Management Engine Interface (Mobile 4 Series Chipset)'
class = simple comms

I've added this device to the code, and loaded it:

heci0: <Intel ICH9 (Cantiga) Express HECI/MEI Controller> mem 0xff9ffff0-0xff9fffff irq 16 at device 3.0 on pci0
heci0: using MSI
heci0: [ITHREAD]
heci0: found ME client at address 0x02:
heci0: status = 0x00
heci0: protocol_name(guid) = BB875E12-CB58-4D14-AE93-8566183C66C7
heci0: found ME client at address 0x06:
heci0: status = 0x00
heci0: protocol_name(guid) = 9B27FD6D-EF72-4967-BCC2-471A32679620
heci0: found ME client at address 0x07:
heci0: status = 0x00
heci0: protocol_name(guid) = 55213584-9A29-4916-BADF-0FB7ED682AEB
heci0: found ME client at address 0x20:
heci0: status = 0x00
heci0: protocol_name(guid) = 309DCDE8-CCB1-4062-8F78-600115A34327
heci0: found ME client at address 0x21:
heci0: status = 0x00
heci0: protocol_name(guid) = 23F27E9B-9D26-4FCE-9227-DE06446E5B06
heci0: found ME client at address 0x22:
heci0: status = 0x00
heci0: protocol_name(guid) = 6733A4DB-0476-4E7B-B3AF-BCFC29BEE7A7
heci0: found ME client at address 0x23:
heci0: status = 0x00
heci0: protocol_name(guid) = 12F80028-B4B7-4B2D-ACA8-46E0FF65814C
heci0: found ME client at address 0x24:
heci0: status = 0x00
heci0: protocol_name(guid) = 05B79A6F-4628-4D7F-899D-A91514CB32AB

However, running the heci-qst.c program you supplied:

psi# ./heci-qst
ioctl HECI_CONNECT: No such file or directory

And output to the console:

heci0: could not find ME client with given guid: 6B5205B9-8185-4519-B889-D98724B58607

Other than seeing that it doesn't appear in the list above, I don't know
if this is expected or not...

Secondly, I get a panic on module unlaod. I haven't spent any time
looking at this, if you haven't fixed it yet let me know and I'll look
into it further.
I'm not even sure how it's getting that far into the detach routine before
panicing, if dev really does = 0xdeadc0dedeadc0de

#8 0xffffffff808580d3 in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:224
#9 0xffffffff8057ac3c in mtx_destroy (m=0xdeadc0dedeadc10e)
at /usr/src/sys/kern/kern_mutex.c:827
#10 0xffffffff812221c6 in heci_detach ()
from /usr/src/sys/modules/heci/heci.ko
#11 0xffffffff805b44d4 in device_detach (dev=0xdeadc0dedeadc0de)
at device_if.h:212
#12 0xffffffff805b4ac0 in driver_module_handler (mod=0xffffff0002d0f800,
what=Variable "what" is not available.
) at /usr/src/sys/kern/subr_bus.c:1156
#13 0xffffffff80578fc5 in module_unload (mod=0xffffff0002d0f800)
at /usr/src/sys/kern/kern_module.c:266
#14 0xffffffff8056fc0b in linker_file_unload (file=0xffffff0002c9c200,
flags=0) at /usr/src/sys/kern/kern_linker.c:633
#15 0xffffffff805707c3 in kern_kldunload (td=0xffffff0002950380,
fileid=Variable "fileid" is not available.
) at /usr/src/sys/kern/kern_linker.c:1092

Let me know if there's anything else I can test.

Thanks,

Gavin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

help needed to fix contrib/ee crash/exit when receiving SIGWINCH

2009-11-09T12:24:46Z

since you've tested the patch on 7-stable do think it's mature enough to be
committed to that branch?

alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T11:24:56Z

here's the final patch. would be great if somebody could commit this one. the
only thing i'm not 100% sure about are the burncd(8) changes. i'm not that
familiar with the man syntax.

thanks go out to keramida@ and des@ for their help.

alex

...just realised the topic makes no sense. ;) what i meant to write was
probably "[patch] burncd: honour envar SPEED". ;)

Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199064)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -27,7 +27,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd May 2, 2005
+.Dd Nov 9, 2009
.Os
.Dt BURNCD 8
.Sh NAME
@@ -158,7 +158,11 @@
.Sh ENVIRONMENT
The following environment variables affect the execution of
.Nm :
-.Bl -tag -width ".Ev CDROM"
+.Bl -tag -width ".Ev BURNCD_SPEED"
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
.It Ev CDROM
The CD device to use if one is not specified with the
.Fl f
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,20 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
+ if (strcasecmp("max", env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", env_speed);
+ }
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T11:03:13Z

Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best
> <alexbestms@...> wrote:
> >Giorgos Keramidas schrieb am 2009-11-09:
> >> > i don't quite get why the value supplied with the envar has to
> >> > be
> >> > validated. if the user supplies a speed value using the -s
> >> > switch
> >> > no validation (except <= 0) is being performed either.

> >> This is probably me being paranoid. I'd prefer *both* places to
> >> check the supplied value for invalid values, even if the check is
> >> something like "negative numbers are not ok".

> >> > also i think there's a speed check in the atapi code. if the
> >> > speed
> >> > requested is > the maximum driver speed it gets set to the
> >> > maximum
> >> > driver speed automatically.

> >> Your patch is fine, but as a followup commit I'd probably like
> >> seeing
> >> atoi() go away. AFAICT, it currently allows invalid speed values,
> >> defaulting to speed=0 when a user types:

> >> burncd -s foobar [options ...]

> >> We can fix that later though :)

> > ok. so do you think this patch is sufficient then? once committed
> > i'll
> > see if i can add some extra validation to the envar as well as the
> > -s
> > switch and will also have a look at the validation the ATA code is
> > doing atm.

> Yes, the patch attached below is fine, and IMO it would be ok to
> commit
> it, minus a couple of tiny details: sorting the BURNCD_SPEED
> environment
> variable before the current CDROM item in the manpage, and bumping
> the
> manpage modification date near .Dd to today.

> %%%
> Index: usr.sbin/burncd/burncd.8
> ===================================================================
> --- usr.sbin/burncd/burncd.8 (revision 199064)
> +++ usr.sbin/burncd/burncd.8 (working copy)
> @@ -164,6 +164,12 @@
> .Fl f
> flag.
> .El
> +.Bl -tag -width ".Ev BURNCD_SPEED"
> +.It Ev BURNCD_SPEED
> +The write speed to use if one is not specified with the
> +.Fl s
> +flag.
> +.El
> .Sh FILES
> .Bl -tag -width ".Pa /dev/acd0"
> .It Pa /dev/acd0
> Index: usr.sbin/burncd/burncd.c
> ===================================================================
> --- usr.sbin/burncd/burncd.c (revision 199064)
> +++ usr.sbin/burncd/burncd.c (working copy)
> @@ -80,11 +80,20 @@
> int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0,
> preemp = 0;
> int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> - const char *dev;
> + const char *dev, *env_speed;

> if ((dev = getenv("CDROM")) == NULL)
> dev = "/dev/acd0";

> + if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
> + if (strcasecmp("max", env_speed) == 0)
> + speed = CDR_MAX_SPEED;
> + else
> + speed = atoi(env_speed) * 177;
> + if (speed <= 0)
> + errx(EX_USAGE, "Invalid speed: %s",
> env_speed);
> + }
> +
> while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> switch (ch) {
> case 'd':
> %%%

ok. thanks a lot. maybe somebody will step up and commit this. i'm not
familiar with the man() syntax so i might need some time to add the changes
you recommended. also it seems the ENVIREMENT section needs to be aligned
differently now that it has more than > 1 entry.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T10:07:29Z

On Mon, 09 Nov 2009 19:01:43 +0100 (CET), Alexander Best <alexbestms@...> wrote:

>Giorgos Keramidas schrieb am 2009-11-09:
>> > i don't quite get why the value supplied with the envar has to be
>> > validated. if the user supplies a speed value using the -s switch
>> > no validation (except <= 0) is being performed either.
>
>> This is probably me being paranoid. I'd prefer *both* places to
>> check the supplied value for invalid values, even if the check is
>> something like "negative numbers are not ok".
>
>> > also i think there's a speed check in the atapi code. if the speed
>> > requested is > the maximum driver speed it gets set to the maximum
>> > driver speed automatically.
>
>> Your patch is fine, but as a followup commit I'd probably like seeing
>> atoi() go away. AFAICT, it currently allows invalid speed values,
>> defaulting to speed=0 when a user types:
>
>> burncd -s foobar [options ...]
>
>> We can fix that later though :)
>
> ok. so do you think this patch is sufficient then? once committed i'll
> see if i can add some extra validation to the envar as well as the -s
> switch and will also have a look at the validation the ATA code is
> doing atm.

Yes, the patch attached below is fine, and IMO it would be ok to commit
it, minus a couple of tiny details: sorting the BURNCD_SPEED environment
variable before the current CDROM item in the manpage, and bumping the
manpage modification date near .Dd to today.

%%%
Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199064)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -164,6 +164,12 @@
.Fl f
flag.
.El
+.Bl -tag -width ".Ev BURNCD_SPEED"
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
+.El
.Sh FILES
.Bl -tag -width ".Pa /dev/acd0"
.It Pa /dev/acd0
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,20 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
+ if (strcasecmp("max", env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", env_speed);
+ }
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':
%%%

attachment0 (201 bytes) Download Attachment

Re: [patch] burncd: honour for envar SPEED

2009-11-09T10:01:43Z

Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best
> <alexbestms@...> wrote:
> > Giorgos Keramidas schrieb am 2009-11-09:
> >> Hi Alexander,

> >> The idea seems very good, but since the value of SPEED is user
> >> supplied data, I would rather see a bit of validation code after
> >> getenv(). With this version of the patch, burncd would happily
> >> accept and try to use values that are quite absurd, i.e.:

> >> env SPEED=12234567890 burncd ...

> >> It may also be sensible to do the translation from "human
> >> readable"
> >> speed values and the multiplication with 177 _after_ the value has
> >> been parsed from getenv(), so that e.g. one can write:

> >> env SPEED=4 burncd

> >> and get behavior similar to the current default.

> > i don't quite get why the value supplied with the envar has to be
> > validated. if the user supplies a speed value using the -s switch
> > no
> > validation (except <= 0) is being performed either.

> This is probably me being paranoid. I'd prefer *both* places to
> check
> the supplied value for invalid values, even if the check is something
> like "negative numbers are not ok".

> > also i think there's a speed check in the atapi code. if the speed
> > requested is > the maximum driver speed it gets set to the maximum
> > driver speed automatically.

> If the capping happens automatically we're fine. From a cursory look
> at
> the kernel sources this morning, I didn't manage to find a
> speed-range
> check in sys/dev/ata. The acd_set_speed() code is a small function:

> : static int
> : acd_set_speed(device_t dev, int rdspeed, int wrspeed)
> : {
> : int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed,
> : wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0,
> 0, 0, 0 };
> : int error;
> :
> : error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30);
> : if (!error)
> : acd_get_cap(dev);
> : return error;
> : }

> and that's all. It probably relies on the hardware to cap the speed,
> but I am not very familiar with the rest of the ATA code to be sure.

> Your patch is fine, but as a followup commit I'd probably like seeing
> atoi() go away. AFAICT, it currently allows invalid speed values,
> defaulting to speed=0 when a user types:

> burncd -s foobar [options ...]

> We can fix that later though :)

ok. so do you think this patch is sufficient then? once committed i'll see if
i can add some extra validation to the envar as well as the -s switch and will
also have a look at the validation the ATA code is doing atm.

alex

Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199064)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -164,6 +164,12 @@
.Fl f
flag.
.El
+.Bl -tag -width ".Ev BURNCD_SPEED"
+.It Ev BURNCD_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
+.El
.Sh FILES
.Bl -tag -width ".Pa /dev/acd0"
.It Pa /dev/acd0
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,20 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ if ((env_speed = getenv("BURNCD_SPEED")) != NULL) {
+ if (strcasecmp("max", env_speed) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", env_speed);
+ }
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

2009-11-09T07:57:52Z

John Baldwin schrieb am 2009-11-09:
> On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote:
> > no problem. i've sent the final patch as followup to kern/71258 and
> > also
> > attached it to this message. to make it short. what's being changed
> > by the
> > patch:

> > 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL
> > 2) if MAP_STACK is defined and offset !=0 ====> offset = 0

> > would be great if you could have a look at the patch if you've got
> > a spare
> > minute.

> I didn't think 2) changed? I.e. both the old and new code do this,
> so only 1)
> is changing?

you're right sorry about that mistake. so the only aspect of mmap() the patch
changes is:

if MAP_ANON is defined and offset !=0 ====> return EINVAL

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T06:52:09Z

On Mon, 09 Nov 2009 15:28:29 +0100 (CET), Alexander Best <alexbestms@...> wrote:

> Giorgos Keramidas schrieb am 2009-11-09:
>> Hi Alexander,
>
>> The idea seems very good, but since the value of SPEED is user
>> supplied data, I would rather see a bit of validation code after
>> getenv(). With this version of the patch, burncd would happily
>> accept and try to use values that are quite absurd, i.e.:
>
>> env SPEED=12234567890 burncd ...
>
>> It may also be sensible to do the translation from "human readable"
>> speed values and the multiplication with 177 _after_ the value has
>> been parsed from getenv(), so that e.g. one can write:
>
>> env SPEED=4 burncd
>
>> and get behavior similar to the current default.
>
> i don't quite get why the value supplied with the envar has to be
> validated. if the user supplies a speed value using the -s switch no
> validation (except <= 0) is being performed either.

This is probably me being paranoid. I'd prefer *both* places to check
the supplied value for invalid values, even if the check is something
like "negative numbers are not ok".

> also i think there's a speed check in the atapi code. if the speed
> requested is > the maximum driver speed it gets set to the maximum
> driver speed automatically.

If the capping happens automatically we're fine. From a cursory look at
the kernel sources this morning, I didn't manage to find a speed-range
check in sys/dev/ata. The acd_set_speed() code is a small function:

: static int
: acd_set_speed(device_t dev, int rdspeed, int wrspeed)
: {
: int8_t ccb[16] = { ATAPI_SET_SPEED, 0, rdspeed >> 8, rdspeed,
: wrspeed >> 8, wrspeed, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
: int error;
:
: error = ata_atapicmd(dev, ccb, NULL, 0, 0, 30);
: if (!error)
: acd_get_cap(dev);
: return error;
: }

and that's all. It probably relies on the hardware to cap the speed,
but I am not very familiar with the rest of the ATA code to be sure.

Your patch is fine, but as a followup commit I'd probably like seeing
atoi() go away. AFAICT, it currently allows invalid speed values,
defaulting to speed=0 when a user types:

burncd -s foobar [options ...]

We can fix that later though :)

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T06:39:14Z

Giorgos Keramidas schrieb am 2009-11-09:
> On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best
> <alexbestms@...> wrote:
> > any thoughts on these small changes to burncd?

> > Index: usr.sbin/burncd/burncd.c
> > ===================================================================
> > --- usr.sbin/burncd/burncd.c (revision 199064)
> > +++ usr.sbin/burncd/burncd.c (working copy)
> > @@ -78,13 +78,16 @@
> > {
> > int arg, addr, ch, fd;
> > int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0,
> > preemp = 0;
> > - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> > + int nogap = 0, speed = 0, test_write = 0, force = 0;
> > int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> > const char *dev;

> > if ((dev = getenv("CDROM")) == NULL)
> > dev = "/dev/acd0";

> > + if ((speed = getenv("SPEED")) == NULL)
> > + speed = 4 * 177;
> > +
> > while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> > switch (ch) {
> > case 'd':

> Hi Alexander,

> The idea seems very good, but since the value of SPEED is user
> supplied
> data, I would rather see a bit of validation code after getenv().
> With
> this version of the patch, burncd would happily accept and try to use
> values that are quite absurd, i.e.:

> env SPEED=12234567890 burncd ...

> It may also be sensible to do the translation from "human readable"
> speed values and the multiplication with 177 _after_ the value has
> been
> parsed from getenv(), so that e.g. one can write:

> env SPEED=4 burncd

> and get behavior similar to the current default.

i don't quite get why the value supplied with the envar has to be validated.
if the user supplies a speed value using the -s switch no validation (except
<= 0) is being performed either.

also i think there's a speed check in the atapi code. if the speed requested
is > the maximum driver speed it gets set to the maximum driver speed
automatically.

cheers.
alex
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: mmap(2) with MAP_ANON honouring offset although it shouldn't

2009-11-09T06:31:12Z

On Saturday 07 November 2009 9:19:05 pm Alexander Best wrote:
> no problem. i've sent the final patch as followup to kern/71258 and also
> attached it to this message. to make it short. what's being changed by the
> patch:
>
> 1) if MAP_ANON is defined and offset !=0 ====> return EINVAL
> 2) if MAP_STACK is defined and offset !=0 ====> offset = 0
>
> would be great if you could have a look at the patch if you've got a spare
> minute.

I didn't think 2) changed? I.e. both the old and new code do this, so only 1)
is changing?

--
John Baldwin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: Why is default value of NKPT so small? mfsroot

2009-11-09T06:27:04Z

On Friday 06 November 2009 2:19:51 pm Trever wrote:

> Does anyone know what the thinking is behind the default value of NKTP in /usr/src/sys/i386/include/pmap.h?
>
> It seems to me that it's too small, though I'm wondering if there are some considerations in changing it's value that I should know about.
>
> Too small because: making it a little more than twice as large (so you can get about a 300MB mfsroot to boot) means you can (by default) boot a standard FreeBSD system into memory, and I know I can't be the only one who would value that a great deal for many reasons. As it stands you have to ax things out (like depenguinator does, for example). Or you have to recompile the kernel.
>
> Does it have to be like this?
>
> Which leads me to two more questions:
> - is it possible to change the NKTP value without recompiling the kernel? I think there isn't but I'll ask.
> - is it possible to change the NKTP value without editing pmap.h (can I pass a variable into the kernel build process)?

I keep meaning to make NKPT a kernel option for i386. Try this patch, it
should let you add 'options NKPT=xxx' to your kernel config.

Index: conf/options.i386
===================================================================
--- conf/options.i386 (revision 198997)
+++ conf/options.i386 (working copy)
@@ -12,6 +12,7 @@
MAXMEM
MPTABLE_FORCE_HTT
MP_WATCHDOG
+NKPT opt_pmap.h
PERFMON
PMAP_SHPGPERPROC opt_pmap.h
POWERFAIL_NMI opt_trap.h
Index: i386/i386/mp_machdep.c
===================================================================
--- i386/i386/mp_machdep.c (revision 198997)
+++ i386/i386/mp_machdep.c (working copy)
@@ -30,6 +30,7 @@
#include "opt_cpu.h"
#include "opt_kstack_pages.h"
#include "opt_mp_watchdog.h"
+#include "opt_pmap.h"
#include "opt_sched.h"
#include "opt_smp.h"

Index: i386/xen/mp_machdep.c
===================================================================
--- i386/xen/mp_machdep.c (revision 198997)
+++ i386/xen/mp_machdep.c (working copy)
@@ -31,6 +31,7 @@
#include "opt_cpu.h"
#include "opt_kstack_pages.h"
#include "opt_mp_watchdog.h"
+#include "opt_pmap.h"
#include "opt_sched.h"
#include "opt_smp.h"

--
John Baldwin
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T04:32:21Z

Giorgos Keramidas <keramida@...> writes:
> Dag-Erling Smørgrav <des@...> wrote:
> > man 3 expand_number
> I know, but thanks. In this case, expand_number's logic for parsing
> possible SI suffixes is not useful and may be slightly confusing.
>
> I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option,
> for example.

Hmm, I thought the speed was expressed in kBps or something...

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-09T03:37:22Z

On Mon, 09 Nov 2009 11:00:43 +0100, Dag-Erling Smørgrav <des@...> wrote:
> Giorgos Keramidas <keramida@...> writes:
>> atoi() doesn't really have error checking and it does not necessarily
>> affect `errno'.
>
> man 3 expand_number

I know, but thanks. In this case, expand_number's logic for parsing
possible SI suffixes is not useful and may be slightly confusing.

I'm not sure what CDROM_SPEED='4m' would mean for burncd's -s option,
for example.

> And please don't call it SPEED or WRITE_SPEED or anything generic; call
> it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar
> used to specify the device is called CDROM, not DEVICE.

Good point.

attachment0 (201 bytes) Download Attachment

Re: [patch] burncd: honour for envar SPEED

2009-11-09T02:00:43Z

Giorgos Keramidas <keramida@...> writes:
> atoi() doesn't really have error checking and it does not necessarily
> affect `errno'.

man 3 expand_number

And please don't call it SPEED or WRITE_SPEED or anything generic; call
it BURNCD_SPEED or CDROM_BURN_SPEED or something unambiguous. The envar
used to specify the device is called CDROM, not DEVICE.

DES
--
Dag-Erling Smørgrav - des@...
_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-08T23:19:33Z

On Mon, 09 Nov 2009 02:22:36 +0100 (CET), Alexander Best <alexbestms@...> wrote:

> --- burncd.c.typo 2009-11-09 02:19:47.000000000 +0100
> +++ burncd.c 2009-11-09 02:20:27.000000000 +0100
> @@ -85,8 +85,8 @@
> if ((dev = getenv("CDROM")) == NULL)
> dev = "/dev/acd0";
>
> - if ((env_speed = getenv("WRITE_SPEED")) != NULL)
> - if (strcasecmp("max", getenv) == 0)
> + if ((env_speed = getenv("WRITE_SPEED")) != NULL) {
> + if (strcasecmp("max", env_speed) == 0)
> speed = CDR_MAX_SPEED;
> else
> speed = atoi(env_speed) * 177;

atoi() doesn't really have error checking and it does not necessarily
affect `errno'. I'd probably prefer something that uses strtoul() and a
few more value/range checks, i.e.:

: #include <limits.h>
: #include <string.h>
:
: {
: char *endp;
: long xspeed;
:
: speed = 4 * 177;
: if ((env_speed = getenv("SPEED")) != NULL) {
: if (strcasecmp("max", env_speed) == 0) {
: speed = CDR_MAX_SPEED;
: } else {
: end = NULL;
: errno = 0;
: xspeed = strtol(env_speed, &endp, 0);
: if (errno != 0 || (endp != NULL && endp != str &&
: *endp != '\0' && (isdigit(*endp) != 0 ||
: isspace(*endp) == 0)))
: err(1, "invalid write speed: %s", env_speed);
: if (xspeed < 0 || xspeed > INT_MAX)
: err(1, "write speed out of range: %ld", xspeed);
: speed = (int)xspeed * 177;
: }
: }
: }

attachment0 (201 bytes) Download Attachment

Re: [patch] burncd: honour for envar SPEED

2009-11-08T23:10:06Z

On Mon, 09 Nov 2009 01:47:40 +0100 (CET), Alexander Best <alexbestms@...> wrote:

> any thoughts on these small changes to burncd?
>
> Index: usr.sbin/burncd/burncd.c
> ===================================================================
> --- usr.sbin/burncd/burncd.c (revision 199064)
> +++ usr.sbin/burncd/burncd.c (working copy)
> @@ -78,13 +78,16 @@
> {
> int arg, addr, ch, fd;
> int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> + int nogap = 0, speed = 0, test_write = 0, force = 0;
> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> const char *dev;
>
> if ((dev = getenv("CDROM")) == NULL)
> dev = "/dev/acd0";
>
> + if ((speed = getenv("SPEED")) == NULL)
> + speed = 4 * 177;
> +
> while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
> switch (ch) {
> case 'd':

Hi Alexander,

The idea seems very good, but since the value of SPEED is user supplied
data, I would rather see a bit of validation code after getenv(). With
this version of the patch, burncd would happily accept and try to use
values that are quite absurd, i.e.:

env SPEED=12234567890 burncd ...

It may also be sensible to do the translation from "human readable"
speed values and the multiplication with 177 _after_ the value has been
parsed from getenv(), so that e.g. one can write:

env SPEED=4 burncd

and get behavior similar to the current default.

attachment0 (201 bytes) Download Attachment

Re: [patch] burncd: honour for envar SPEED

2009-11-08T17:22:36Z

Gabor Kovesdan schrieb am 2009-11-09:

> Gabor Kovesdan escribió:
> >Alexander Best escribió:
> >>any thoughts on these small changes to burncd?
> >> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> >>+ int nogap = 0, speed = 0, test_write = 0, force = 0;
> >> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> >> const char *dev;
> >> if ((dev = getenv("CDROM")) == NULL)
> >> dev = "/dev/acd0";
> >>+ if ((speed = getenv("SPEED")) == NULL)
> >>+ speed = 4 * 177;
> >>+
> >It seems incorrect. The speed variable is of type int, while getenv
> >returns char *. You should first assign getenv("SPEED") to a char *
> >variable and if it isn't NULL then you should convert it to int or
> >fall back to the default value otherwise.
> And one more thing. Personally, I think that a more
> specific/descriptive name would be better, e.g. BURNCD_SPEED. SPEED
> is just too general.

> --
> Gabor Kovesdan
> FreeBSD Volunteer

> EMAIL: gabor@... .:|:. gabor@...
> WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org

ooops. this one fixes the typos. ;)

alex

--- burncd.c.typo 2009-11-09 02:19:47.000000000 +0100
+++ burncd.c 2009-11-09 02:20:27.000000000 +0100
@@ -85,8 +85,8 @@
if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

- if ((env_speed = getenv("WRITE_SPEED")) != NULL)
- if (strcasecmp("max", getenv) == 0)
+ if ((env_speed = getenv("WRITE_SPEED")) != NULL) {
+ if (strcasecmp("max", env_speed) == 0)
speed = CDR_MAX_SPEED;
else
speed = atoi(env_speed) * 177;

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-08T17:19:05Z

Gabor Kovesdan schrieb am 2009-11-09:

> --
> Gabor Kovesdan
> FreeBSD Volunteer

> EMAIL: gabor@... .:|:. gabor@...
> WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org

thanks for the help. how about this revised patch?

cheers.
alex

Index: usr.sbin/burncd/burncd.8
===================================================================
--- usr.sbin/burncd/burncd.8 (revision 199064)
+++ usr.sbin/burncd/burncd.8 (working copy)
@@ -164,6 +164,12 @@
.Fl f
flag.
.El
+.Bl -tag -width ".Ev WRITE_SPEED"
+.It Ev WRITE_SPEED
+The write speed to use if one is not specified with the
+.Fl s
+flag.
+.El
.Sh FILES
.Bl -tag -width ".Pa /dev/acd0"
.It Pa /dev/acd0
Index: usr.sbin/burncd/burncd.c
===================================================================
--- usr.sbin/burncd/burncd.c (revision 199064)
+++ usr.sbin/burncd/burncd.c (working copy)
@@ -80,11 +80,20 @@
int dao = 0, eject = 0, fixate = 0, list = 0, multi = 0, preemp = 0;
int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
- const char *dev;
+ const char *dev, *env_speed;

if ((dev = getenv("CDROM")) == NULL)
dev = "/dev/acd0";

+ if ((env_speed = getenv("WRITE_SPEED")) != NULL)
+ if (strcasecmp("max", getenv) == 0)
+ speed = CDR_MAX_SPEED;
+ else
+ speed = atoi(env_speed) * 177;
+ if (speed <= 0)
+ errx(EX_USAGE, "Invalid speed: %s", env_speed);
+ }
+
while ((ch = getopt(argc, argv, "def:Flmnpqs:tv")) != -1) {
switch (ch) {
case 'd':

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-08T17:02:36Z

Gabor Kovesdan escribió:

> Alexander Best escribió:
>> any thoughts on these small changes to burncd?
>> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
>> + int nogap = 0, speed = 0, test_write = 0, force = 0;
>> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
>> const char *dev;
>>
>> if ((dev = getenv("CDROM")) == NULL)
>> dev = "/dev/acd0";
>>
>> + if ((speed = getenv("SPEED")) == NULL)
>> + speed = 4 * 177;
>> +
> It seems incorrect. The speed variable is of type int, while getenv
> returns char *. You should first assign getenv("SPEED") to a char *
> variable and if it isn't NULL then you should convert it to int or
> fall back to the default value otherwise.

And one more thing. Personally, I think that a more specific/descriptive
name would be better, e.g. BURNCD_SPEED. SPEED is just too general.

--
Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor@... .:|:. gabor@...
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."

Re: [patch] burncd: honour for envar SPEED

2009-11-08T16:53:14Z

Alexander Best escribió:

> any thoughts on these small changes to burncd?
>
> - int nogap = 0, speed = 4 * 177, test_write = 0, force = 0;
> + int nogap = 0, speed = 0, test_write = 0, force = 0;
> int block_size = 0, block_type = 0, cdopen = 0, dvdrw = 0;
> const char *dev;
>
> if ((dev = getenv("CDROM")) == NULL)
> dev = "/dev/acd0";
>
> + if ((speed = getenv("SPEED")) == NULL)
> + speed = 4 * 177;
> +

It seems incorrect. The speed variable is of type int, while getenv
returns char *. You should first assign getenv("SPEED") to a char *
variable and if it isn't NULL then you should convert it to int or fall
back to the default value otherwise.

--
Gabor Kovesdan
FreeBSD Volunteer

EMAIL: gabor@... .:|:. gabor@...
WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org

_______________________________________________
freebsd-hackers@... mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@..."