Re: Minor typo in fread.3
On Wed, Mar 04, 2015 at 09:08:21PM -0700, Ryan T May wrote: > I found a minor typo in the manpage for fread(3). > > Thanks, > Ryan May Fixed, thanks! > > Index: fread.3 > === > RCS file: /cvs/src/lib/libc/stdio/fread.3,v > retrieving revision 1.8 > diff -u -r1.8 fread.3 > --- fread.3 1 May 2014 16:40:36 - 1.8 > +++ fread.3 5 Mar 2015 03:11:41 - > @@ -87,7 +87,7 @@ > If the product of > .Fa size > and > -.Fa nemb > +.Fa nmemb > results in integer overflow, 0 is returned and errno > is set to > .Er EOVERFLOW . >
Minor typo in fread.3
I found a minor typo in the manpage for fread(3). Thanks, Ryan May Index: fread.3 === RCS file: /cvs/src/lib/libc/stdio/fread.3,v retrieving revision 1.8 diff -u -r1.8 fread.3 --- fread.3 1 May 2014 16:40:36 - 1.8 +++ fread.3 5 Mar 2015 03:11:41 - @@ -87,7 +87,7 @@ If the product of .Fa size and -.Fa nemb +.Fa nmemb results in integer overflow, 0 is returned and errno is set to .Er EOVERFLOW .
freetype vulns
Freetype (http://www.freetype.org/) 2.5.5 was released a little while ago, fixing some security vulnerabilities. Actually as I understand it, 2.5.4 fixed the vulns, then 2.5.5 fixed the fix. OpenBSD 5.7 will ship with 2.5.5; 5.6 shipped with 2.5.3 and is therefore vulnerable. The changelog for 2.5.4: http://sourceforge.net/projects/freetype/files/freetype2/2.5.4/ references this bug: http://savannah.nongnu.org/bugs/?43661 However, it's not immediately clear from that bug what the fixes are. The diff between 2.5.3 and 2.5.5 is quite large: diff -ru freetype-2.5.3 freetype-2.5.5 | wc 62922 249726 2923547 That's much too large a patch for us to provide as an errata fix. There is some discussion of this issue in RedHat's bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1172633 Again, however, it's not immediately clear which patches are required for a complete, working fix or if this bug references all of them. Ubuntu's security advisory: http://www.ubuntu.com/usn/usn-2510-1/ references no fewer than 20 CVEs which would make me think we are searching for somewhere in the neighborhood of 20 patches. Unfortunately, the FreeType project does not appear to have made these patches available separately from the releases, which makes it difficult for us to apply backports to OpenBSD.
Re: touchpad slight regression (snap: 20141121->20150217)
Sorry, I must have missed this mail. This patch also seems to work with a snapshot kernel I downloaded a few minutes ago.
Re: touchpad slight regression (snap: 20141121->20150217)
Is anyone doing something about this regression for 5.7?
The time window to apply a fix is basically over *now*.
On Sat, Feb 28, 2015 at 05:01:46PM +0100, Ulf Brosziewski wrote:
> On 02/28/2015 09:38 AM, Martin Pieuchot wrote:
> >[moved to tech@]
> >
> >On 27/02/15(Fri) 11:40, patrick keshishian wrote:
> >>Hi,
> >>
> >>On 2/26/15, Ulf Brosziewski wrote:
> >>>On 02/27/2015 03:31 AM, Ulf Brosziewski wrote:
> >>>...>
> It might be that the following patch to wsmouse.c solves the problem
> with the new version of wsconscomm. Tests would be welcome (I could
> only verify that the patch does no harm to other touchpad types, i.e.,
> Elantech-v4 and Alps Glidepoint).
> >>[...]
> >>>
> >>>Sorry, the change was in the wrong place and would only do a half of
> >>>the work. It should look like:
> >>>
> >>>Index: wsmouse.c
> >>>===
> >>>RCS file: /cvs/src/sys/dev/wscons/wsmouse.c,v
> >>>retrieving revision 1.26
> >>>diff -u -p -r1.26 wsmouse.c
> >>>--- wsmouse.c 27 Oct 2014 13:55:05 - 1.26
> >>>+++ wsmouse.c 27 Feb 2015 02:50:06 -
> >>>@@ -433,6 +433,9 @@ wsmouse_input(struct device *wsmousedev,
> >>> }
> >>> }
> >>>
> >>>+ if (sc->sc_z == 0)
> >>>+ sc->sc_w = INVALID_W;
> >>>+
> >>> mb = sc->sc_mb;
> >>> while ((d = mb ^ ub) != 0) {
> >>> /*
> >>
> >>I can confirm this change alone causes no adverse, observable
> >>change on my x120e's touchpad.
> >
> >I the long term, I think that having a similar logic in wsmouse_input()
> >makes sense. As I already told Ulf, it would be really nice to improve
> >the wsmouse(4)/wscons(4) layer to support modern touchpad features and
> >get rid of wsconscomm.
> >
> >But right now this chunk is really intrusive. Plus I believe it should
> >only be applied on touchpad ``native'' mode. Sure, we could be able to
> >check for WSMOUSE_INPUT_ABSOLUTE_W, but can it be a bad idea?
> >
> >What about putting a similar chunk in pms_proc_synpatics() instead?
> >
> >>However, I would appreciate it if someone could enlighten me
> >>as to what the Z and W axis refer.
> >
> >I'm glad you asked, because it really depends on which hardware you're
> >using :) Plus right now our code use magic values which are most of
> >the time not documented. Diffs are more than welcome to improve the
> >situation.
> >
> >Martin
> >
> >
>
> I was a bit hasty with that patch. I reasoned that sc_z is initialized
> with INT_MAX, and it is only used in native mode. Later I thought that
> change to wsconscomm might be a better (short-term) solution, something
> like the code below. But it doesn't look less odd than the other patch,
> or does it?
>
> It is not clear to me how a purely local change to pms_proc_input()
> could help here. As long as we don't add or redefine event types, or
> introduce a special convention for W values, the only way to circumvent
> the problem might be to produce an additional event at the start of
> a two-finger touch (i.e., to change W from 0 to 1 and back again).
>
>
> diff --git a/wsconscomm.c b/wsconscomm.c
> index f6b9d88..78f47ab 100644
> --- a/wsconscomm.c
> +++ b/wsconscomm.c
> @@ -217,6 +217,14 @@ WSConsReadHwState(InputInfoPtr pInfo,
> if (hw->z == 0) {
> hw->fingerWidth = 0;
> hw->numFingers = 0;
> +} else if (hw->numFingers == 0) {
> +/*
> + * Because W may be 0 already, a two-finger touch on a
> + * Synaptics touchpad doesn't necessarily produce an update
> + * event for W.
> + */
> +hw->fingerWidth = 5;
> +hw->numFingers = 2;
> }
> hw->millis = 1000 * event.time.tv_sec + event.time.tv_nsec /
> 100;
> SynapticsCopyHwState(hwRet, hw);
OpenBSD Foundation GSOC 2015
The OpenBSD Foundation is pleased to announce that we have been accepted as a mentoring organization for Google Summer of Code 2015. As such if you are a student who qualifies to apply for GSOC, you will be able to find us in Google's Summer of Code Application process.For details on the application process and the relevant timelines please see https://www.google-melange.com/gsoc/homepage/google/gsoc2015 We have an ideas page which is located at http://www.openbsdfoundation.org/gsoc2015.html I will repeat my usual disclaimer here on behalf of the foundation - doing anything with GSOC does *not* guarantee the result will end up in OpenBSD or any related project. That having been said we hope to be able to put some mentors together with students to accomplish things that may become useful to the community at large. Ken Westerback, The OpenBSD Foundation
Re: Questions about 802.11n support
On Wed, Mar 04, 2015 at 08:52:34AM +0100, Mark Kettenis wrote: > > * How much work is required? Is the work required in the order of days, > > weeks, months? > > Depends. 11n station support is probably something of the order of > days to a couple of -weeks. AP support is likely to be significantly > more work. The actual amount of work depends on when you consider support complete. 11n has such a large feature set and optional parts that you can't simply say "this is an 11n device" to explain what your device can do. Are you done when one driver supports 11n? When all drivers capable of 11n support it? Out of the 77 modulation and coding schemes, which ones do you want? For stations the minimum is 8 out of those, which leaves you with a maximum 72Mbit/s (single-channel at 2Ghz). APs need at least 16 of them (maximum 144Mbit/s). Do you want 150Mbit/s (single antenna maximum)? Or do you require MIMO (multiple antennas), with a maximum of 300Mbit/s with 2 antennas? 450 Mbit/s with 3 antennas? 600Mbit/s with 4 antennas? > > * Would parts of FreeBSD's implementation be useful, or are the two > > network stacks different enough that a new implementation is > > required? > > The OpenBSD 802.11 stack already has 11n bits in it. They have not > really been tested though, so more fixes will be necessay. I don't > think the FreeBSD code is going to help much. > > I expect most of the work to be in driver code. Based on code and literature I've read so far, I would agree here. > > I'm a relatively competent C programmer, but I have very little > > experience with kernel code, much less network protocols. I would > > like to use OpenBSD as an access point, but I need wireless-n @ 5GHz in > > order to do so, so I'm motivated enough to allocate some time for > > testing and even writing code. I could probably also supply some basic > > hardware if that would help, though I don't have a big budget. > > I don't want to discourage you, but AP support for 11n will be quite > an effort. Even if somebody gets 11n to work, I think it will be hard > work to make it work well. Some people here will claim that OpenBSD > 11a/11g APs don't really work very well. My 11a athn(4) AP is working quite well. Apart from the fact that the soekris hardware won't really keep up when I pump data from cable to antenna at 54Mbit/s. 11n support would definitely require slightly more modern hardware ;-)
