Re: txt-sysinstall scrapped
On Fri, Nov 5, 2010 at 10:17 PM, Josh Paetzel jpaet...@freebsd.org wrote: On Friday, November 05, 2010 11:48:27 pm Garrett Cooper wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? Sorry -- missed the SSL note. Other questions still outstanding :). Thanks! -Garrett Without putting much analysis into it, we talked about using lighttpd, which is BSDL. As far as another service, it would be running for the install only which is in most circumstances something that happens locally. Right. Lighttpd was relatively light and small (but back in the day at my other job at Cisco when I was testing it I remember it ran under 10MB, and the another thing such as Lynx ran about 5MB -- this was on ppc 32 though... MIPS 64-bit was a bit more heavyweight IIRC). Is Lynx a good idea though? It is a GPL tool (and whilst I agree that we shouldn't be really investing any time in modifying the app, FreeBSD tends to shy away from GPL nowadays)... someone else suggested curl, but then you miss out on the visual representation of the installation process :(... Coming up with a short and sweet http client shouldn't be too hard, but it probably would be more error prone than investing in a preexisting client. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh i...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On Fri, Nov 5, 2010 at 11:04 PM, Garrett Cooper gcoo...@freebsd.org wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh i...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. One other thing to add. If prompts aren't necessary, the process should be completely scripted, so I personally would probably just take the webserver, et all out of the equation. Just seems like unnecessary and problematic overhead requirements... Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On 11/06/2010 00:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Loshi...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? That's exactly what I'm doing, i think. I didn't hear matt's suggestion at all, so I have no idea what you are talking about. my idea was that you could do this with an image you'd DD to a usb stick. For the cdrom, you'd need to do more complicated things, which I hadn't though about earlier... While I thought of this for vm creation mostly, I can see cdrom booting might be desirable too... Then again, determining the root device to date is still a bit kludgy isn't it? Not anymore. ufs labels and glabel make it almost bulletproof. I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. I must be explaining badly. lynx isn't for downloading anything from the web, but connecting to the web-server that's running on your box to configure the box before the install happens. You don't need https for that, and while I suppose we could offer the uber-geek ftp install via command line extensions to ftpd, I hadn't planned on that :) I have no idea what the curl idea is. Maybe you could explain to me what you are suggesting here. Warner Cheers, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On 11/06/2010 00:05, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 11:04 PM, Garrett Coopergcoo...@freebsd.org wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Loshi...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. One other thing to add. If prompts aren't necessary, the process should be completely scripted, so I personally would probably just take the webserver, et all out of the equation. Just seems like unnecessary and problematic overhead requirements... Prompts are required. Of course, we could have an image that would automatically overwrite whatever disk it found when booting, but that's kinda dangerous to have be the default. We really need the web server to run the web app that is the installer front end. I don't see any way around that. Warner Thanks! -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] update to the latest libedit version and remove libreadline deps
Anonymous swel...@gmail.com writes:
Anonymous swel...@gmail.com writes:
Baptiste Daroussin b...@freebsd.org writes:
[...]
You can find the patch against current here:
http://people.freebsd.org/~bapt/update-libedit.patch
$ make depend
/usr/src/lib/libedit/makelist -h /usr/src/lib/libedit/vi.c vi.h.tmp
mv vi.h.tmp vi.h
/usr/src/lib/libedit/makelist: Permission denied
*** Error code 126
I guess HOST_SH is defined by build.sh on NetBSD.
libgdb doesn't build, too
Aww, a few more changes were needed to make buildworld happy.
%%
Index: ObsoleteFiles.inc
===
--- ObsoleteFiles.inc (revision 214854)
+++ ObsoleteFiles.inc (working copy)
@@ -14,6 +14,36 @@
# The file is partitioned: OLD_FILES first, then OLD_LIBS and OLD_DIRS last.
#
+# : readline removed, ports should use devel/readline ;)
+OLD_FILES+=usr/include/readline/chardefs.h
+OLD_FILES+=usr/include/readline/keymaps.h
+OLD_FILES+=usr/include/readline/rlconf.h
+OLD_FILES+=usr/include/readline/rlstdc.h
+OLD_FILES+=usr/include/readline/rltypedefs.h
+OLD_FILES+=usr/include/readline/tilde.h
+OLD_FILES+=usr/lib/libhistory.a
+OLD_FILES+=usr/lib/libhistory_p.a
+OLD_FILES+=usr/lib/libreadline.a
+OLD_FILES+=usr/lib/libreadline_p.a
+OLD_FILES+=usr/share/info/history.info.gz
+OLD_FILES+=usr/share/info/readline.info.gz
+OLD_FILES+=usr/share/info/rluserman.info.gz
+OLD_FILES+=usr/share/man/man3/readline.3.gz
+OLD_FILES+=usr/share/man/man3/rlhistory.3.gz
+OLD_LIBS+=lib/libreadline.so.8
+OLD_LIBS+=usr/lib/libhistory.so
+OLD_LIBS+=usr/lib/libhistory.so.8
+OLD_LIBS+=usr/lib/libreadline.so
+.if ${TARGET_ARCH} == amd64
+OLD_FILES+=usr/lib32/libhistory.a
+OLD_FILES+=usr/lib32/libhistory_p.a
+OLD_FILES+=usr/lib32/libreadline.a
+OLD_FILES+=usr/lib32/libreadline_p.a
+OLD_LIBS+=usr/lib32/libhistory.so
+OLD_LIBS+=usr/lib32/libhistory.so.8
+OLD_LIBS+=usr/lib32/libreadline.so
+OLD_LIBS+=usr/lib32/libreadline.so.8
+.endif
# 20101101: headers moved to machine/ to x86/
.if ${TARGET_ARCH} == amd64 || ${TARGET_ARCH} == i386
OLD_FILES+=usr/include/machine/apicreg.h
Index: contrib/gdb/gdb/cli/cli-cmds.c
===
--- contrib/gdb/gdb/cli/cli-cmds.c (revision 214854)
+++ contrib/gdb/gdb/cli/cli-cmds.c (working copy)
@@ -21,7 +21,6 @@
#include defs.h
#include readline/readline.h
-#include readline/tilde.h
#include completer.h
#include target.h /* For baud_rate, remote_debug and remote_timeout */
#include gdb_wait.h /* For shell escape implementation */
Index: contrib/gdb/gdb/cli/cli-setshow.c
===
--- contrib/gdb/gdb/cli/cli-setshow.c (revision 214854)
+++ contrib/gdb/gdb/cli/cli-setshow.c (working copy)
@@ -18,7 +18,6 @@
Boston, MA 02111-1307, USA. */
#include defs.h
-#include readline/tilde.h
#include value.h
#include ctype.h
#include gdb_string.h
Index: contrib/gdb/gdb/event-top.c
===
--- contrib/gdb/gdb/event-top.c (revision 214854)
+++ contrib/gdb/gdb/event-top.c (working copy)
@@ -34,7 +34,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/top.c
===
--- contrib/gdb/gdb/top.c (revision 214854)
+++ contrib/gdb/gdb/top.c (working copy)
@@ -48,7 +48,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/tracepoint.c
===
--- contrib/gdb/gdb/tracepoint.c(revision 214854)
+++ contrib/gdb/gdb/tracepoint.c(working copy)
@@ -45,7 +45,6 @@
/* readline include files */
#include readline/readline.h
-#include readline/history.h
/* readline defines this. */
#undef savestring
Index: contrib/gdb/gdb/tui/tui-io.c
===
--- contrib/gdb/gdb/tui/tui-io.c(revision 214854)
+++ contrib/gdb/gdb/tui/tui-io.c(working copy)
@@ -397,8 +397,6 @@ static void
tui_rl_display_match_list (char **matches, int len, int max)
{
typedef int QSFUNC (const void *, const void *);
- extern int _rl_qsort_string_compare (const void*, const void*);
- extern int _rl_print_completions_horizontally;
int count, limit, printed_len;
int i, j, k, l;
Index: gnu/lib/Makefile
===
--- gnu/lib/Makefile(revision 214854)
+++ gnu/lib/Makefile(working copy)
@@ -2,7 +2,7 @@
.include bsd.own.mk
-SUBDIR= csu libgcc libgcov libdialog libgomp libregex libreadline libssp
+SUBDIR= csu libgcc libgcov libdialog libgomp libregex libssp
# libsupc++ uses
Re: txt-sysinstall scrapped
On Nov 5, 2010, at 11:49 PM, Warner Losh wrote: On 11/06/2010 00:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Loshi...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? That's exactly what I'm doing, i think. I didn't hear matt's suggestion at all, so I have no idea what you are talking about. Summary: DVD load times are ridiculous; just go straight for a fat (4GB uncompressed, 1.7GB compressed) USB image. I think it's a bit big, but with all of the binary packages in ports, it might be around that size. my idea was that you could do this with an image you'd DD to a usb stick. For the cdrom, you'd need to do more complicated things, which I hadn't though about earlier... While I thought of this for vm creation mostly, I can see cdrom booting might be desirable too... Yeah... I boot from CD by default and so do a number of other users of course (despite the fact that it's an archaic 1980s technology :)...). Then again, determining the root device to date is still a bit kludgy isn't it? Not anymore. ufs labels and glabel make it almost bulletproof. Good point -- forgot about that. Which reminds me that I need to test some geom things related to this. I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. I must be explaining badly. lynx isn't for downloading anything from the web, but connecting to the web-server that's running on your box to configure the box before the install happens. You don't need https for that, and while I suppose we could offer the uber-geek ftp install via command line extensions to ftpd, I hadn't planned on that :) Well... what do you mean by before the install happens? What kind of information would one specify in that state to get the machine from an effectively halted state to a singing and dancing I'm installing FreeBSD state? I have no idea what the curl idea is. Maybe you could explain to me what you are suggesting here. Summary: push and pull data to and from the backend via curl. There wasn't much else to it other than that... Thanks, -Garrett___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On 11/06/2010 01:38, Garrett Cooper wrote: On Nov 5, 2010, at 11:49 PM, Warner Losh wrote: On 11/06/2010 00:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Loshi...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? That's exactly what I'm doing, i think. I didn't hear matt's suggestion at all, so I have no idea what you are talking about. Summary: DVD load times are ridiculous; just go straight for a fat (4GB uncompressed, 1.7GB compressed) USB image. I think it's a bit big, but with all of the binary packages in ports, it might be around that size. ah, ok... my idea was that you could do this with an image you'd DD to a usb stick. For the cdrom, you'd need to do more complicated things, which I hadn't though about earlier... While I thought of this for vm creation mostly, I can see cdrom booting might be desirable too... Yeah... I boot from CD by default and so do a number of other users of course (despite the fact that it's an archaic 1980s technology :)...). CD's are desirable, if possible, but DVDs as a last resort... Then again, determining the root device to date is still a bit kludgy isn't it? Not anymore. ufs labels and glabel make it almost bulletproof. Good point -- forgot about that. Which reminds me that I need to test some geom things related to this. I bring up the former item because I wouldn't want my data going unencrypted across any wire, and what BSD compatible web servers did you guys have in store and who would maintain the server, and what kinds of vulnerabilities would you be introducing by adding a service which would be enabled by default at runtime? The web server would just be there at installation time. You'd run it out of the ram disk and it would evaporate when the system reboots after it being installed. Sure. Also, I'm not sure we even need to have to have a set of prompts. If we do the web page right, we likely can just go directly to lynx... Well... I like the curl idea a lot more for this approach (esp because it supports more protocols than just http and ftp, whereas lynx is constrained to ftp and http for the most part), but having both solutions is more heavyweight for the task than it probably should be. I must be explaining badly. lynx isn't for downloading anything from the web, but connecting to the web-server that's running on your box to configure the box before the install happens. You don't need https for that, and while I suppose we could offer the uber-geek ftp install via command line extensions to ftpd, I hadn't planned on that :) Well... what do you mean by before the install happens? What kind of information would one specify in that state to get the machine from an effectively halted state to a singing and dancing I'm installing FreeBSD state? Before the install happens means before the install happens... The paradigm is that you gather all the info, then write a config file, then go. 'before install happens' is before the 'go'. I have no idea what the curl idea is. Maybe you could explain to me what you are suggesting here. Summary: push and pull data to and from the backend via curl. There wasn't much else to it other than that... ah, ok. so not really relevant to what we have in mind... the web app for the install runs on this box being installed... Warner Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] mptutil(8) - capture errors and percolate up to caller
Similar to r214396, this patch deals with properly capturing error
and passing it up to the caller in mptutil just in case the errno
value gets stomped on by warn*(3); this patch deals with an improper
use of warn(3), and also some malloc(3) errors, as well as shrink down
some static buffers to fit the data being output.
If someone could review and help me commit this patch it would be
much appreciated; all I could do is run negative tests on my local box
and minor positive tests on my vmware fusion instance because it
doesn't fully emulate a fully working mpt(4) device (the vmware
instance consistently crashed with a warning about the mpt
controller's unimplemented features after I poked at it enough).
I'll submit another patch to fix up style(9) in this app if requested.
Thanks!
-Garrett
Index: usr.sbin/mptutil/mpt_evt.c
===
--- usr.sbin/mptutil/mpt_evt.c (revision 214568)
+++ usr.sbin/mptutil/mpt_evt.c (working copy)
@@ -94,18 +94,20 @@
{
CONFIG_PAGE_LOG_0 *log;
MPI_LOG_0_ENTRY **entries;
- int ch, fd, i, num_events, verbose;
+ int ch, error, fd, i, num_events, verbose;
fd = mpt_open(mpt_unit);
if (fd 0) {
+ error = errno;
warn(mpt_open);
- return (errno);
+ return (error);
}
log = mpt_get_events(fd, NULL);
if (log == NULL) {
+ error = errno;
warn(Failed to get event log info);
- return (errno);
+ return (error);
}
/* Default settings. */
@@ -128,6 +130,8 @@
/* Build a list of valid entries and sort them by sequence. */
entries = malloc(sizeof(MPI_LOG_0_ENTRY *) * log-NumLogEntries);
+ if (entries == NULL)
+ return (errno);
num_events = 0;
for (i = 0; i log-NumLogEntries; i++) {
if (log-LogEntry[i].LogEntryQualifier ==
Index: usr.sbin/mptutil/mpt_cam.c
===
--- usr.sbin/mptutil/mpt_cam.c (revision 214568)
+++ usr.sbin/mptutil/mpt_cam.c (working copy)
@@ -63,6 +63,7 @@
struct bus_match_pattern *b;
union ccb ccb;
size_t bufsize;
+ int error;
if (xpt_open() 0)
return (ENXIO);
@@ -91,9 +92,10 @@
b-flags = BUS_MATCH_NAME | BUS_MATCH_UNIT | BUS_MATCH_BUS_ID;
if (ioctl(xptfd, CAMIOCOMMAND, ccb) 0) {
+ error = errno;
free(ccb.cdm.matches);
free(ccb.cdm.patterns);
- return (errno);
+ return (error);
}
free(ccb.cdm.patterns);
@@ -124,7 +126,7 @@
union ccb ccb;
path_id_t path_id;
size_t bufsize;
- int error, i;
+ int error;
/* mpt(4) only handles devices on bus 0. */
if (VolumeBus != 0)
@@ -164,10 +166,10 @@
p-flags = PERIPH_MATCH_PATH | PERIPH_MATCH_NAME | PERIPH_MATCH_TARGET;
if (ioctl(xptfd, CAMIOCOMMAND, ccb) 0) {
- i = errno;
+ error = errno;
free(ccb.cdm.matches);
free(ccb.cdm.patterns);
- return (i);
+ return (error);
}
free(ccb.cdm.patterns);
@@ -236,7 +238,7 @@
ccb = cam_getccb(dev);
if (ccb == NULL)
- return (ENOMEM);
+ return (errno);
/* Zero the rest of the ccb. */
bzero((ccb-ccb_h)[1], sizeof(struct ccb_scsiio) -
@@ -350,7 +352,7 @@
ccb = cam_getccb(dev);
if (ccb == NULL)
- return (ENOMEM);
+ return (errno);
/* Zero the rest of the ccb. */
bzero((ccb-ccb_h)[1], sizeof(struct ccb_scsiio) -
@@ -358,8 +360,9 @@
inq_buf = calloc(1, sizeof(*inq_buf));
if (inq_buf == NULL) {
+ error = errno;
cam_freeccb(ccb);
- return (ENOMEM);
+ return (errno);
}
scsi_inquiry(ccb-csio, 1, NULL, MSG_SIMPLE_Q_TAG, (void *)inq_buf,
SHORT_INQUIRY_LENGTH, 0, 0, SSD_FULL_SIZE, 5000);
@@ -397,8 +400,8 @@
union ccb ccb;
path_id_t path_id;
size_t bufsize;
- u_int i;
int count, error;
+ uint32_t i;
if (xpt_open() 0)
return (ENXIO);
@@ -431,10 +434,10 @@
p-flags = PERIPH_MATCH_PATH | PERIPH_MATCH_NAME;
if (ioctl(xptfd, CAMIOCOMMAND, ccb) 0) {
- i = errno;
+ error = errno;
free(ccb.cdm.matches);
free(ccb.cdm.patterns);
- return (i);
+ return (error);
}
free(ccb.cdm.patterns);
@@ -481,6 +484,8 @@
* exclude them from the list.
*/
ioc2 = mpt_read_ioc_page(fd, 2, NULL);
+ if (ioc2 == NULL)
+ return (errno);
disks = calloc(ccb.cdm.num_matches, sizeof(*disks));
count = 0;
for (i = 0; i ccb.cdm.num_matches; i++) {
Index: usr.sbin/mptutil/mpt_show.c
===
--- usr.sbin/mptutil/mpt_show.c (revision 214568)
+++ usr.sbin/mptutil/mpt_show.c (working copy)
@@ -79,7 +79,7 @@
CONFIG_PAGE_IOC_2 *ioc2;
CONFIG_PAGE_IOC_6 *ioc6;
U16 IOCStatus;
- int fd, comma;
+ int comma, error, fd;
if (ac != 1) {
warnx(show adapter: extra arguments);
@@ -88,17 +88,19 @@
fd = mpt_open(mpt_unit);
if (fd 0) {
+ error = errno;
warn(mpt_open);
- return (errno);
+ return (error);
}
man0 = mpt_read_man_page(fd, 0, NULL);
if (man0 == NULL) {
+ error = errno;
warn(Failed to get controller info);
- return (errno);
+ return (error);
}
if (man0-Header.PageLength sizeof(*man0) / 4) {
- warn(Invalid
Re: [PATCH] update to the latest libedit version and remove libreadline deps
Thanks all for your returns, I'll update my patch during the next week. Concerning the reverts I'll try to reintegrate them and then send them to upstream, Because I think it is better to keep in sync to easier futures updates. regards, Bapt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On 11/06/10 01:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh i...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? But this breaks badly for people who don't own USB sticks of sufficient size, are installing on machines without USB ports, can't boot from USB, want to install from a shared medium like PXE, are installing on blades with convenient shared CD drives but not USB etc. etc. Everything in the world can boot from CD, and we have to ensure that continues working. I also have mixed feelings about needing to use a web browser to instruct a web app inside a bundled web server to write a config file to be interpreted by shell scripts just in order to run gpart, newfs, and tar. But if you get it working, it's better than sysinstall no matter how baroque. -Nathan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Userland debug symbols directory
On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Userland debug symbols directory
On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? Not that easy, since you have to arrange to use libraries from obj/, by LD_LIBRARY_PATH etc. I fully support the work to install symbol files, and it should go into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) is required. pgpjvaPjQz4Lo.pgp Description: PGP signature
Re: Userland debug symbols directory
On Sat, Nov 06, 2010 at 07:56:03PM +0200, Kostik Belousov wrote: On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? Not that easy, since you have to arrange to use libraries from obj/, by LD_LIBRARY_PATH etc. I fully support the work to install symbol files, and it should go into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) is required. Yeah, I just mean that using LD_LIBRARY_PATH or whatever is still a lot easier than realizing you don't have the debug info at all, and trying to rebuild an identical binary or library with debug. I definitely want the changes to build and install the symbol files in the FreeBSD tree. I don't have a huge concern over the exact path we pick. -Ed ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
[PATCH] Simplify uart_bus_pci_probe
Some of the logic could have been simplified in the probe. The proposed patch makes the detection process a tad bit more straightforward. Comments, review (and maybe a commit :P) are more than welcome :). Thanks! -Garrett uart-bus-probe-minor-cleanup.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Simplify uart_bus_pci_probe
On Sat, 6 Nov 2010 11:22:53 -0700 Garrett Cooper gcoo...@freebsd.org wrote: Some of the logic could have been simplified in the probe. The proposed patch makes the detection process a tad bit more straightforward. Comments, review (and maybe a commit :P) are more than welcome :). Thanks! -Garrett This is definitely much less convoluted and easier to understand than the old code! I'd commit it, if I still had my src commit bit :) -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: [PATCH] Add -lssp_nonshared to GCC's LIB_SPEC unconditionally
On Fri, Nov 05, 2010 at 07:00:23PM -0400, Alexander Kabaev wrote:
On Fri, 5 Nov 2010 22:39:06 +0100
Jeremie Le Hen jere...@le-hen.org wrote:
Hi Kib,
On Tue, Oct 05, 2010 at 08:18:04PM +0200, Jeremie Le Hen wrote:
On Mon, Sep 27, 2010 at 06:44:57PM +0300, Kostik Belousov wrote:
Hardcoding /usr/lib as the path to the library in the script looks
problematic. For the buidlworld, you are linking resulting
binaries with the host library, instead of the
buildworld-produced one. For lib32, it makes non-working
combination of 32/64 bit.
Sorry for the late reply, but I had to collect various evidences
for my sayings and my development machine is reaaally slow.
In fact it seems the toolchain built for buildworld contains a ld(1)
binary which invariably bases lookups for libraries in ${WORLDTMP},
even in case of an absolute path. I have two evidences of this:
- Putting /usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a in
/usr/obj/usr/src/tmp/usr/lib/libc.ld leads toolchain's ld(1) to
use /usr/obj/usr/src/tmp/usr/obj/usr/src/tmp/usr/lib/libssp_nonshared.a;
- I also verified this with a hand-wrought opensnoop-like DTrace
script.
I dare to remind you about my patch. Do you have any other concerns?
Thanks.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
Hmm, I thought I did approve this patch already a long time agi, but
since you asked:
+.if defined(SHLIB_LDSCRIPT) exists(${.CURDIR}/${SHLIB_LDSCRIPT})
this should be:
+.if defined(SHLIB_LDSCRIPT)
ditto for all other similar places. Otherwise I do not think we should
hold the patch in queue ans should unleash it on unsuspecting public.
Also, I think the DEBUG lines should be removed.
You install the libxxx.ld and then symlink libxxx.so to libxxx.ld.
Why ? Would it be enough to install just the libxxx.so ?
Otherwise, I think you need the similar
.if ${SHLIBDIR} == ${LIBDIR}
magic, that is better to be avoided.
pgphAtdikJPZD.pgp
Description: PGP signature
Re: txt-sysinstall scrapped
On Nov 6, 2010, at 9:24 AM, Nathan Whitehorn wrote: On 11/06/10 01:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh i...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? But this breaks badly for people who don't own USB sticks of sufficient size, are installing on machines without USB ports, can't boot from USB, want to install from a shared medium like PXE, are installing on blades with convenient shared CD drives but not USB etc. etc. Everything in the world can boot from CD, and we have to ensure that continues working. I also have mixed feelings about needing to use a web browser to instruct a web app inside a bundled web server to write a config file to be interpreted by shell scripts just in order to run gpart, newfs, and tar. But if you get it working, it's better than sysinstall no matter how baroque. -Nathan I find myself identifying a lot with this sentiment. We have FreeBSD running on 1,000+ systems (modestly) within our organization. We've found that some older BIOSes don't boot from USB sticks so-well. It's also hit-or-miss in varied combinations of old-BIOS and off-brand sticks -- had great luck with those super-tiny PNY's that rotate-out, though again, old BIOSes say pre-2003 P4 or AMD K6, have issues). And since we're shipping at a rate of at least 100+ servers a year that are now coming without any optical drives... our solution has been to purchase one of these for each/every field engineer: http://www.lg.com/us/computer-products/optical-media/LG-external-dvd-burner-GP08LU30.jsp This great little device has worked wonders for over 30 field engineers (modestly). Out of thousands upon thousands of installs with the thing, we've really only had a problem with about a half-dozen individual PCs -- but after a BIOS upgrade, they tended to work else we slapped internal ATAPI CD-ROM's in there and they worked). Though, to-date what we've really found great-success in, is employing the latest-and-greatest ISOLINUX boot-loader w/ their `isohybrid' ISO post-processing program which encapsulates the disk-image contents within a hardware-emulation structure (you can make your ISO -- when written to USB stick -- appear to the BIOS as a ZIP disk, Hard Disk, etc.). We currently tell all of our field engineers to download a single ISO that is built with our custom build-process (which employs ISOLINUX and `isohybrid' from http://syslinux.zytor.com/). This ISO can then optionally -- at the field engineer's discretion -- either burn that ISO to optical media and use the LG AC-Adapterless USB optical drive (linked to above), OR ... they can use dd(1) to write the ISO directly to a USB stick (though again... some older BIOSes prefer the optical over flash media). This was, of course, quite a challenge to achieve. Here's a brief (lol -- it started that way, you got to believe me) list of what we did to accomplish installs with one ISO on two mediums: 1. Entire swaths of sysinstall(8) were patched Out of the 48 source files that make up sysinstall (that I count currently within RELENG_8), we've thus far patched 28 of them and added 1 new file. We even added a new feature ... ability to install from a directory rather than a device. In install.cfg, we have something akin to: nullfs=/path/to/freebsd/release mediaSetNullFS As implied by the name, a nullfs is done from the directory specified to /dist -- where sysinstall(8) expects to find the mounted distribution, regardless of what media you select. 2. One tiny kernel patch There's a feature in the kernel for forcing the boot-medium into read-write mode (which is not the default... the default is to mount read-only and switch it during boot-up). When we're mounting an mfsroot, especially one that's been customized to run scripts which build the `install.cfg' script to hand-off to sysinstall(8), you _want_ to mount read-write out of the gate. This feature is enabled by setting the environment variable vfs.root.mountfrom.options to rw in the loader's Forth name-space (in loader.rc for example). Well, this was broken. : ( So we patched it : ) 3. One tiny patch to the release(7) Makefile Since we rely on the
Re: Userland debug symbols directory
On Sat, Nov 06, 2010 at 02:04:20PM -0400, Ed Maste wrote: On Sat, Nov 06, 2010 at 07:56:03PM +0200, Kostik Belousov wrote: On Sat, Nov 06, 2010 at 01:36:20PM -0400, Ed Maste wrote: On Fri, Nov 05, 2010 at 10:45:19PM +0200, Gleb Kurtsou wrote: I like the idea a lot, but why not to leave symbol files in /usr/obj, The application where this is most useful (and why we implemented it originally) is the case where /usr/obj isn't available - for instance, a binary installation other than where the source tree was built. If you're going to keep /usr/obj around anyway then you can get most of the benefit by just keeping the unstripped binaries / libs in there, no? Not that easy, since you have to arrange to use libraries from obj/, by LD_LIBRARY_PATH etc. I fully support the work to install symbol files, and it should go into /usr, might be /usr/lib/debug. Possibly, some change to gdb (config) is required. Yeah, I just mean that using LD_LIBRARY_PATH or whatever is still a lot easier than realizing you don't have the debug info at all, and trying to rebuild an identical binary or library with debug. I definitely want the changes to build and install the symbol files in the FreeBSD tree. I don't have a huge concern over the exact path we pick. -Ed FWIW, the default path is #defined in gnu/usr.bin/gdb/arch/*/config.h as DEBUGDIR. I suppose that could be changed on a system-by-system basis using a global configuration file, but apparently such a file needs to be defined at compile time: http://sourceware.org/gdb/onlinedocs/gdb/System_002dwide-configuration.html#System_002dwide-configuration I don't have a strong opinion on the location, /usr/lib/debug seems fine to me. -Mark ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: txt-sysinstall scrapped
On Nov 6, 2010, at 1:33 PM, Devin Teske dte...@vicor.com wrote: On Nov 6, 2010, at 9:24 AM, Nathan Whitehorn wrote: On 11/06/10 01:04, Garrett Cooper wrote: On Fri, Nov 5, 2010 at 10:06 PM, Warner Losh i...@bsdimp.com wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? https or ssh. We're also toying with the idea of having a partition that you could 'dd' your certs and keys to (so any system can customize the image with keys to make sure you were talking to who you think you are). We'd just reserve 1MB of space on partition s3. We'd then check to see if there was a tar ball. If so, we'd extract it and do the intelligent thing with the keys we find there. Wouldn't it be better just to go with a read-write media solution (USB) like Matt Dillon was suggesting at today then? Then again, determining the root device to date is still a bit kludgy isn't it? But this breaks badly for people who don't own USB sticks of sufficient size, are installing on machines without USB ports, can't boot from USB, want to install from a shared medium like PXE, are installing on blades with convenient shared CD drives but not USB etc. etc. Everything in the world can boot from CD, and we have to ensure that continues working. I also have mixed feelings about needing to use a web browser to instruct a web app inside a bundled web server to write a config file to be interpreted by shell scripts just in order to run gpart, newfs, and tar. But if you get it working, it's better than sysinstall no matter how baroque. -Nathan I find myself identifying a lot with this sentiment. We have FreeBSD running on 1,000+ systems (modestly) within our organization. We've found that some older BIOSes don't boot from USB sticks so-well. It's also hit-or-miss in varied combinations of old-BIOS and off-brand sticks -- had great luck with those super-tiny PNY's that rotate-out, though again, old BIOSes say pre-2003 P4 or AMD K6, have issues). And since we're shipping at a rate of at least 100+ servers a year that are now coming without any optical drives... our solution has been to purchase one of these for each/every field engineer: http://www.lg.com/us/computer-products/optical-media/LG-external-dvd-burner-GP08LU30.jsp This great little device has worked wonders for over 30 field engineers (modestly). Out of thousands upon thousands of installs with the thing, we've really only had a problem with about a half-dozen individual PCs -- but after a BIOS upgrade, they tended to work else we slapped internal ATAPI CD-ROM's in there and they worked). Though, to-date what we've really found great-success in, is employing the latest-and-greatest ISOLINUX boot-loader w/ their `isohybrid' ISO post-processing program which encapsulates the disk-image contents within a hardware-emulation structure (you can make your ISO -- when written to USB stick -- appear to the BIOS as a ZIP disk, Hard Disk, etc.). We currently tell all of our field engineers to download a single ISO that is built with our custom build-process (which employs ISOLINUX and `isohybrid' from http://syslinux.zytor.com/). This ISO can then optionally -- at the field engineer's discretion -- either burn that ISO to optical media and use the LG AC-Adapterless USB optical drive (linked to above), OR ... they can use dd(1) to write the ISO directly to a USB stick (though again... some older BIOSes prefer the optical over flash media). This was, of course, quite a challenge to achieve. Here's a brief (lol -- it started that way, you got to believe me) list of what we did to accomplish installs with one ISO on two mediums: 1. Entire swaths of sysinstall(8) were patched Out of the 48 source files that make up sysinstall (that I count currently within RELENG_8), we've thus far patched 28 of them and added 1 new file. We even added a new feature ... ability to install from a directory rather than a device. In install.cfg, we have something akin to: nullfs=/path/to/freebsd/release mediaSetNullFS As implied by the name, a nullfs is done from the directory specified to /dist -- where sysinstall(8) expects to find the mounted distribution, regardless of what media you select. 2. One tiny kernel patch There's a feature in the kernel for forcing the boot-medium into read-write mode (which is not the default... the default is to mount read-only and switch it during boot-up). When we're mounting an mfsroot, especially one that's been customized to run scripts which build the `install.cfg' script to hand-off to sysinstall(8), you _want_ to mount read-write out of the gate. This feature is enabled by setting the environment variable vfs.root.mountfrom.options to rw in the loader's Forth name-space (in loader.rc for
Re: txt-sysinstall scrapped
On Nov 5, 2010, at 10:17 PM, Josh Paetzel wrote: On Friday, November 05, 2010 11:48:27 pm Garrett Cooper wrote: Just to add to that (because I do find it a novel idea), 1) how are you going to properly prevent man in the middle attacks (SSL, TLS, etc?), and 2) what webserver would you use? Without putting much analysis into it, we talked about using lighttpd, which is BSDL. As far as another service, it would be running for the install only which is in most circumstances something that happens locally. The whole idea makes a huge amount of sense to me. Besides the usual application HTTP servers, there are also quite a few HTTP server libraries that could be embedded into the installer. Even without SSL support, this would be a big win for both local installs and for installs within a controlled network. Supporting installs over the public Internet would be an interesting project, but certainly does not need to be a goal of the first iteration. Can't wait to see this in action! Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
