Re: pkg_* new functionality: arch, version expansion
On 2015/04/15 23:33, Marc Espie wrote: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? As far as I am concerned, -beta should act exactly the same as no tag or -stable, i.e. use the release number. Otherwise it is hard to vetify that a release is going to do the right thing.
Re: [PATCH] Add support for dumping descriptors to usbdevs(8)
On 16/04/15(Thu) 10:02, Dimitris Papastamos wrote: ping A bit too soon to ping ;) You could wait at least a week!
Re: pkg_* new functionality: arch, version expansion
On 2015/04/16 12:03, Sebastian Reitenbach wrote: Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) There is also the period when the release version is 5.7 but before packages/firmware are available on mirrors in the 5.7 directory (and actually this usually lasts for longer than the beta phase). I don't have an answer for this, but it seems out-of-scope of what is being done here, as people who know they will always be using snapshots can just insert the word snapshots in the URL themselves rather than using this variable.
Re: [PATCH] Add support for dumping descriptors to usbdevs(8)
On Thu, Apr 16, 2015 at 12:06:49PM +0200, Martin Pieuchot wrote: On 13/04/15(Mon) 17:49, Dimitris Papastamos wrote: Hi, Attached below an updated patch that makes the layout a bit more sensible. It's nice it works. Now like various students that applied for the GSoC you've done the first step. The interesting part of that GSoC is also the boring part: the parser. How are you gonna deal with AUDIO, VIDEO and HID descriptors? I'm asking the question but I'm not really interested in the answer. I don't see the point of having multiple people working on the same task. But if a student is selected for this task, you might want to discuss that with him. Sure, that makes sense. Honestly if you are looking for an easy task to contribute to the USB land in OpenBSD you could have asked before, there's a lot to do :) I should have I guess. The gsoc page was tempting even if I am not a student. So here's a small task, just for you: can you add an option to usbdev(8) to enable/disable USB bus probing? By default it would be on, just like know: when you plug a device is it detected/attached. If you turn it off to new device will be attached and port events will simply be acknowledged? Will have a look at that.
Re: [NEW] Driver for the Araneus Alea II USB TRNG
On 15/04/15(Wed) 10:46, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
On 14/04/15(Tue) 15:22, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
};
Is it possible to match your device based on the content of the device
descriptor instead of whitelisting IDs? Whitelisting means that if the
company produce a compatible device with a new ID we'll need to modify
the driver.
Sadly, I don't think it is possible... you mean by looking at
bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
[...]
Perhaps I am misunderstanding; is there something else in there I
could/should match on? I've changed the attach routine in the updated
version to check vendor/product/iface, at least.
I was thinking at bInterfaceClass and bInterfaceProtocol but when they
are both to vendor defined (255), matching against the ID is the right
thing to do.
I looked and it appears that M_ZERO is used when allocating the memory
for all of these structures, so I take it that explicit zeroing of
things when tearing down is neither required nor desired? I removed
this kind of thing from ualea.c because it looked like it wasn't
necessary.
That's right.
I'm attaching the updated driver.
Thank you for the critique. I suppose I need to write a man page for
this as well... working on it.
Perfect, I'll put it in tree together with your driver :)
Man page attached. I am also attaching an updated copy of the driver
(only copyright changed).
Thanks so much for your help. I look forward to contributing more.
Committed thanks. I removed some unneeded headers and applied jmc@'s
tweak.
In the future I'd suggest you to send unified diff against the CVS tree,
it's easier to apply test!
Cheers,
Martin
Re: pkg_* new functionality: arch, version expansion
Am 4/16/2015 um 12:03 PM schrieb Sebastian Reitenbach: Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames I meant %c here that gets expanded in that case. where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) Sebastian
Re: [PATCH] Add support for dumping descriptors to usbdevs(8)
ping
Re: pkg_* new functionality: arch, version expansion
Am 4/15/2015 um 11:33 PM schrieb Marc Espie: On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach wrote: I've seen at least -beta versions short before release locks. Not sure if there are -alpha too? Those should be treated same way as snapshots, I think. This is the exact same logic that's in fw_update, actually... so if one is wrong, the other one would be too ? Well, when running pkg_add on a host that has version like X.X-beta, pkg_add will expand %v to /X.X/ in the path. Usually at those time frames where there are -beta versions, such directories aren't on the mirrors (yet), as far as I can see, pkg_add will fail then. Just wondering, if is this intended? I also might be wrong ;) Sebastian
Re: [PATCH] Add support for dumping descriptors to usbdevs(8)
On 13/04/15(Mon) 17:49, Dimitris Papastamos wrote: Hi, Attached below an updated patch that makes the layout a bit more sensible. It's nice it works. Now like various students that applied for the GSoC you've done the first step. The interesting part of that GSoC is also the boring part: the parser. How are you gonna deal with AUDIO, VIDEO and HID descriptors? I'm asking the question but I'm not really interested in the answer. I don't see the point of having multiple people working on the same task. But if a student is selected for this task, you might want to discuss that with him. Honestly if you are looking for an easy task to contribute to the USB land in OpenBSD you could have asked before, there's a lot to do :) So here's a small task, just for you: can you add an option to usbdev(8) to enable/disable USB bus probing? By default it would be on, just like know: when you plug a device is it detected/attached. If you turn it off to new device will be attached and port events will simply be acknowledged?
Re: pkg_* new functionality: arch, version expansion
On Thu, Apr 16, 2015 at 11:19:39AM BST, Stuart Henderson wrote:
On 2015/04/16 12:03, Sebastian Reitenbach wrote:
Am 4/15/2015 um 11:33 PM schrieb Marc Espie:
On Wed, Apr 15, 2015 at 08:39:15PM +0200, Sebastian Reitenbach
wrote:
I've seen at least -beta versions short before release locks. Not
sure if there are -alpha too? Those should be treated same way as
snapshots, I think.
This is the exact same logic that's in fw_update, actually... so
if one is wrong, the other one would be too ?
Well, when running pkg_add on a host that has version like X.X-beta,
pkg_add will expand %v to /X.X/ in the path. Usually at those time
frames where there are -beta versions, such directories aren't on
the mirrors (yet), as far as I can see, pkg_add will fail then.
Just wondering, if is this intended? I also might be wrong ;)
There is also the period when the release version is 5.7 but before
packages/firmware are available on mirrors in the 5.7 directory (and
actually this usually lasts for longer than the beta phase).
I don't have an answer for this, but it seems out-of-scope of what is
being done here, as people who know they will always be using
snapshots can just insert the word snapshots in the URL themselves
rather than using this variable.
That's what I've been doing in my {install,upgrade}.conf after finding
it out the hard way[0].
[0] https://marc.info/?l=openbsd-techm=142554965809503w=2
Cheers,
Raf
Re: On github now
Well, lets begin. In the future, I wish to have fd_getfile() returning acquired fp instance. The goal is to not to have pointer to destroyed fp instance in FREF()/FRELE()/fd_getfile() races. This one requres modification of getsock(), getvnode() and dupfdopen() functions, they must receive pointer to struct proc instance for FRELE() call on referenced fp instance while they have internal error cases. While getsock(), getvnode() and dupfdopen() functions are called, struct proc instance exists, so their struct filedesc * arg can be replaced by struct proc * arg which contains pointer to struct filedesc”. The races will be appeared right after at least one FRELE(), FREF() or fd_getfile() call will be done outside kernel lock. The “outside kernel lock call capability requires a little more refactoring, but for this functions only, not system-wide. Now we have something like: if((fp = fd_getfile(fds, fd)) == NULL) goto error; /* * fp can be destroyed here by FRELE() call on other cpu */ FREF(fp); The goal is to avoid this situation. Should I checkout CURRENT and patch it or 5.7 is fine too? I attach already exitig patches for git tree. If it required, I'll remake them and send one after another. P.S. I'm not a native speaker and my english is ugly. Sorry. 0001-getsock-api-modification.patch Description: Binary data 0002-getvnode-api-modification.patch Description: Binary data 0003-dupfdopen-api-modification.patch Description: Binary data 0004-fd_getfile-returns-acquired-fp-instance-now.patch Description: Binary data
[PATCH] Re: Multiple cmsghdrs in msghdr
This documents the error code when passing multiple cmsg structs. Let me know if the wording needs to be improved. Index: lib/libc/sys/send.2 === RCS file: /cvs/src/lib/libc/sys/send.2,v retrieving revision 1.31 diff -u -p -r1.31 send.2 --- lib/libc/sys/send.2 9 Sep 2014 06:32:37 - 1.31 +++ lib/libc/sys/send.2 16 Apr 2015 12:48:32 - @@ -223,6 +223,17 @@ values in the .Fa msg_iov array overflowed an .Em ssize_t . +.It Bq Er EINVAL +The socket +.Fa s +is a +.Xr unix 4 +socket, and +.Em controlmsg +is an invalid size or multiple +.Em controlmsg +structures were passed as part of +.Fa msg . .It Bq Er EMSGSIZE The .Fa msg_iovlen signature.asc Description: OpenPGP digital signature
Re: [NEW] Driver for the Araneus Alea II USB TRNG
Martin Pieuchot m...@openbsd.org writes:
On 15/04/15(Wed) 10:46, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
On 14/04/15(Tue) 15:22, attila wrote:
Martin Pieuchot m...@openbsd.org writes:
static const struct usb_devno ualea_devs[] = {
{ USB_VENDOR_ARANEUS, USB_PRODUCT_ARANEUS_ALEA }
};
Is it possible to match your device based on the content of the device
descriptor instead of whitelisting IDs? Whitelisting means that if the
company produce a compatible device with a new ID we'll need to modify
the driver.
Sadly, I don't think it is possible... you mean by looking at
bDeviceClass/bDeviceSubClass/bDeviceProtocol? He only gives me zeroes
[...]
Perhaps I am misunderstanding; is there something else in there I
could/should match on? I've changed the attach routine in the updated
version to check vendor/product/iface, at least.
I was thinking at bInterfaceClass and bInterfaceProtocol but when they
are both to vendor defined (255), matching against the ID is the right
thing to do.
I looked and it appears that M_ZERO is used when allocating the memory
for all of these structures, so I take it that explicit zeroing of
things when tearing down is neither required nor desired? I removed
this kind of thing from ualea.c because it looked like it wasn't
necessary.
That's right.
I'm attaching the updated driver.
Thank you for the critique. I suppose I need to write a man page for
this as well... working on it.
Perfect, I'll put it in tree together with your driver :)
Man page attached. I am also attaching an updated copy of the driver
(only copyright changed).
Thanks so much for your help. I look forward to contributing more.
Committed thanks. I removed some unneeded headers and applied jmc@'s
tweak.
In the future I'd suggest you to send unified diff against the CVS tree,
it's easier to apply test!
After this was committed I received a critique of the driver from the
person behind the Alea II (Andreas Gustafsson) who made a few pretty
good points. He felt trying to pull all the entropy off of the device
that would theoretically be available every second was a losing
strategy for several reasons. Most importantly I ended up calling
add_true_randomness() in bursts of 3200 calls every trip through
ualea_task() whereas rnd_event_space[] in rnd.c only has 64 entries on
a 32bit machine (42 on amd64); this almost surely means that the vast
majority of my calls are no-ops... not so useful, it appears.
The attached diff cranks the buffer size way down and now we call
add_true_randomness() 32 times every 100ms. When I crank ALEA_MSECS
below 100ms I start to notice the load increases on the machine with
an Alea II plugged in. I guess this is because the stuff that happens
in ualea_task() happens in the context of a process and that process
always appears to be runnable when ALEA_MSECS is e.g. 10ms. I crank
the read timeout up to 5000ms because that's what he recommends in his
sample code; under normal circumstances we never time out.
The diff also explicitly looks for endpoint #1 because that's the
endpoint that Andreas says to use, not necc. the first one that I
find; as it turns out now the first one I find is the right one but
just to be safe it's better to check explicitly.
Maybe now this is closer to production-worthy. All feedback and
comments most welcome.
Cheers,
Martin
Pax, -A
--
att...@stalphonsos.com | http://trac.haqistan.net/~attila
keyid E6CC1EDB | 4D91 1B98 A210 1D71 2A0E AC29 9677 D0A6 E6CC 1EDB
Index: ualea.c
===
RCS file: /cvs/src/sys/dev/usb/ualea.c,v
retrieving revision 1.1
diff -u -p -r1.1 ualea.c
--- ualea.c 16 Apr 2015 08:55:21 - 1.1
+++ ualea.c 16 Apr 2015 20:34:59 -
@@ -36,9 +36,10 @@
#include dev/rndvar.h
#define ALEA_IFACE 0
+#define ALEA_ENDPOINT 1
#define ALEA_MSECS 100
-#define ALEA_READ_TIMEOUT 1000
-#define ALEA_BUFSIZ((1024/8)*100) /* 100 kbits */
+#define ALEA_READ_TIMEOUT 5000
+#define ALEA_BUFSIZ128
#define DEVNAME(_sc) ((_sc)-sc_dev.dv_xname)
@@ -101,7 +102,8 @@ ualea_attach(struct device *parent, stru
return;
}
if (UE_GET_DIR(ed-bEndpointAddress) == UE_DIR_IN
- UE_GET_XFERTYPE(ed-bmAttributes) == UE_BULK) {
+ UE_GET_XFERTYPE(ed-bmAttributes) == UE_BULK
+ UE_GET_ADDR(ed-bEndpointAddress) == ALEA_ENDPOINT) {
ep_ibulk = ed-bEndpointAddress;
break;
}
Byte range implementation for httpd(8)
Range requests as defined in RFC7233 is required for resuming
interrupted http(s) downloads for example:
ftp -C http://foo.bar/install57.iso
With this diff, httpd parses Range header in the requests and
provide either 206(Partial Content) or 416(Range not Satisfiable)
responses with Content-Range header set appropriately. Further,
it understands multi range request and generate satisfiable payloads
with multipart/byteranges media type.
Suggestions/comments to improve the diff are welcome.
Note, If-Range isn't implemented yet.
Index: server_file.c
===
RCS file: /cvs/src/usr.sbin/httpd/server_file.c,v
retrieving revision 1.51
diff -u -p -r1.51 server_file.c
--- server_file.c 12 Feb 2015 10:05:29 - 1.51
+++ server_file.c 17 Apr 2015 02:22:12 -
@@ -36,12 +36,23 @@
#define MINIMUM(a, b) (((a) (b)) ? (a) : (b))
#define MAXIMUM(a, b) (((a) (b)) ? (a) : (b))
+#define MAX_RANGES 4
+
+struct range {
+ off_t start;
+ off_t end;
+};
int server_file_access(struct httpd *, struct client *, char *, size_t);
int server_file_request(struct httpd *, struct client *, char *,
struct stat *);
+int server_partial_file_request(struct httpd *, struct client *, char *,
+ struct stat *, char *);
int server_file_index(struct httpd *, struct client *, struct stat *);
int server_file_method(struct client *);
+int parse_range_spec(char *, size_t, struct range *);
+struct range *parse_range(char *, size_t, int *);
+int buffer_add_range(int, struct evbuffer *, struct range *);
int
server_file_access(struct httpd *env, struct client *clt,
@@ -50,6 +61,7 @@ server_file_access(struct httpd *env, st
struct http_descriptor *desc = clt-clt_descreq;
struct server_config*srv_conf = clt-clt_srv_conf;
struct stat st;
+ struct kv *r, key;
char*newpath;
int ret;
@@ -123,7 +135,13 @@ server_file_access(struct httpd *env, st
goto fail;
}
- return (server_file_request(env, clt, path, st));
+ key.kv_key = Range;
+ r = kv_find(desc-http_headers, key);
+ if (r != NULL)
+ return (server_partial_file_request(env, clt, path, st,
+ r-kv_value));
+ else
+ return (server_file_request(env, clt, path, st));
fail:
switch (errno) {
@@ -262,6 +280,138 @@ server_file_request(struct httpd *env, s
}
int
+server_partial_file_request(struct httpd *env, struct client *clt, char *path,
+struct stat *st, char *range_str)
+{
+ struct http_descriptor *resp = clt-clt_descresp;
+ struct media_type *media, multipart_media;
+ struct range*range;
+ struct evbuffer *evb = NULL;
+ size_t content_length;
+ int code = 500, fd = -1, i, nranges, ret;
+ char content_range[64];
+ const char *errstr = NULL;
+ uint32_t boundary;
+
+ if ((range = parse_range(range_str, st-st_size, nranges)) == NULL) {
+ code = 416;
+ (void)snprintf(content_range, sizeof(content_range),
+ bytes */%lld, st-st_size);
+ errstr = content_range;
+ goto abort;
+ }
+
+ /* Now open the file, should be readable or we have another problem */
+ if ((fd = open(path, O_RDONLY)) == -1)
+ goto abort;
+
+ media = media_find(env-sc_mediatypes, path);
+ if ((evb = evbuffer_new()) == NULL) {
+ errstr = failed to allocate file buffer;
+ goto abort;
+ }
+
+ if (nranges == 1) {
+ (void)snprintf(content_range, sizeof(content_range),
+ bytes %lld-%lld/%lld, range-start, range-end,
+ st-st_size);
+ if (kv_add(resp-http_headers, Content-Range,
+ content_range) == NULL)
+ goto abort;
+
+ content_length = range-end - range-start + 1;
+ if (buffer_add_range(fd, evb, range) == 0)
+ goto abort;
+
+ } else {
+ content_length = 0;
+ boundary = arc4random();
+ /* Generate a multipart payload of byteranges */
+ while (nranges--) {
+ if ((i = evbuffer_add_printf(evb, \r\n--%ud\r\n,
+ boundary)) == -1)
+ goto abort;
+
+ content_length += i;
+ if ((i = evbuffer_add_printf(evb,
+ Content-Type: %s/%s\r\n,
+ media == NULL ? application : media-media_type,
+ media == NULL ?
+
