Re: [RFC] remove GNU rcs from FreeBSD 12
On 11/02/2016 19:17, Julian Elischer wrote: On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote: On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote: hi, For long we are planning to remove GNU rcs from base, after a failed attempt before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD 12. why should we remove it? What will replace it? it's an integral part of many people's systems. Is there a non gnu RCS with the same features? surprised to hear so many people are dependent upon having rcs in their base system. there are options though - for example OpenBSD uses OpenRCS in their base: http://man.openbsd.org/rcs.1 its not strictly GNU compliant as I believe it adheres to the original implementation (which frankly is probably a good thing imho). GNU RCS is also available via ports/pkgs as well. If people are adamant about preserving a rcs binary in base though this seems like a great opportunity to step up and help import/support OpenRCS. just my two bits - hope it helps. -pete ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] remove GNU rcs from FreeBSD 12
On 26/10/2016 2:27 AM, Eivind Nicolay Evensen wrote: On Sun, Sep 11, 2016 at 03:38:04PM +0200, Baptiste Daroussin wrote: hi, For long we are planning to remove GNU rcs from base, after a failed attempt before FreeBSD 10.0. Let see where we are to be able to remove it from FreeBSD 12. why should we remove it? What will replace it? it's an integral part of many people's systems. Is there a non gnu RCS with the same features? Whatever the outcome may be and for whatever my opinion is worth, I hope rcs will stay in base. I don't care about the licensing. I don't care if a switch to openrcs happens either, as long as it works. For years, one has been able to rely upon this operating system having certain pieces of software available. Losing that makes it a worse choice than before. I've already had to readd cvs to my freebsd tree since that was removed, but if it keeps getting worse and worse and there's soon a freebsd kernel and some random bits of freebsd userland available through ports, there's not much reason to keep using it as an operating system, because then it is not an operating system anymore, rather an emulation of another "system" built around that concept. Eivind N. E. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: copyinstr and ENAMETOOLONG
On Wed, Nov 02, 2016 at 02:24:43PM -0500, Eric van Gyzen wrote:
> Does copyinstr guarantee that it has filled the output buffer when it
> returns ENAMETOOLONG? I usually try to answer my own questions, but I
> don't speak many dialects of assembly. :)
The few I checked appear to work by checking the length while copying,
but the man page copy(9) does not guarantee that, and similar code in
sys/compat/linux/linux_misc.c linux_prctl() LINUX_PR_SET_NAME performs a
copyin() if copyinstr() fails with [ENAMETOOLONG].
In implementing copyinstr(), checking the length first may make sense
for economy of code: a user-strnlen() using an algorithm like
lib/libc/string/strlen.c and a copyin() connected together with a C
copyinstr(). This would probably be faster than the current amd64 code
(which uses lods and stos, meh). With that implementation, filling the
buffer in the [ENAMETOOLONG] case requires a small piece of additional
code.
> I ask because I'd like to make the following change, and I'd like to
> know whether I should zero the buffer before calling copyinstr to ensure
> that I don't set the thread's name to the garbage that was on the stack.
> Index: kern_thr.c
> ===
> --- kern_thr.c(revision 308217)
> +++ kern_thr.c(working copy)
> @@ -580,8 +580,13 @@ sys_thr_set_name(struct thread *td, struct thr_set
> if (uap->name != NULL) {
> error = copyinstr(uap->name, name, sizeof(name),
> NULL);
> - if (error)
> - return (error);
> + if (error) {
> + if (error == ENAMETOOLONG) {
> + name[sizeof(name) - 1] = '\0';
> + } else {
> + return (error);
> + }
> + }
> }
> p = td->td_proc;
> ttd = tdfind((lwpid_t)uap->id, p->p_pid);
For API design, it makes more sense to set error = 0 if a truncated name
is being set anyway. This preserves the property that the name remains
unchanged if the call fails.
A change to the man page thr_set_name(2) is needed in any case.
--
Jilles Tjoelker
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
copyinstr and ENAMETOOLONG
Does copyinstr guarantee that it has filled the output buffer when it
returns ENAMETOOLONG? I usually try to answer my own questions, but I
don't speak many dialects of assembly. :)
I ask because I'd like to make the following change, and I'd like to
know whether I should zero the buffer before calling copyinstr to ensure
that I don't set the thread's name to the garbage that was on the stack.
Eric
Index: kern_thr.c
===
--- kern_thr.c (revision 308217)
+++ kern_thr.c (working copy)
@@ -580,8 +580,13 @@ sys_thr_set_name(struct thread *td, struct thr_set
if (uap->name != NULL) {
error = copyinstr(uap->name, name, sizeof(name),
NULL);
- if (error)
- return (error);
+ if (error) {
+ if (error == ENAMETOOLONG) {
+ name[sizeof(name) - 1] = '\0';
+ } else {
+ return (error);
+ }
+ }
}
p = td->td_proc;
ttd = tdfind((lwpid_t)uap->id, p->p_pid);
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwm -> rtwm
> On 2 Nov 2016, at 15:54, Mattia Rossi > wrote: > > >>> Hi! >>> >>> rtwn_usb(4) depends on rtwn(4) module; you can try to >>> 1) add them to the kernel config; >>> 2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables >>> 3) compile / install them manually >>> >>> P.S. There is no 'rtwm' module in the tree; what is the exact error message >>> where it was? >> the problem was that if_rtwn.ko was not compiled! >> all the others where, i.e. if_rtwn_[pci,usb].ko. >> I added all of them to the config, and now it seems to work >> >> so the problem is that the loadable module if_rtwn.ko is NOT compiled >> by default, while all the others are, >> what is the magic to have it compiled? > From my experience you always have to specify all modules and the modules > they depend on. I for example had to specify this for zfs support in the > config file: > > makeoptions MODULES_OVERRIDE="zfs opensolaris acl_nfs4" > > I actually only wanted zfs, which depends on opensolaris which then again > depends on acl_nfs4 (probably because I sepcified nfs4 support in the config > file) > not from my experience, the fact that all the other rtwn- where there means that somewhere there is a missing directive. > I only found out after a few tries. It's really not ideal, that module > dependencies are not resolved. > But once you know about it, you can live with it :-) > >> >> BTW, I tried this on RPI2, and now will try on an orangepi one. > Is that the SDIO based internal WiFi? Let me know if it works! > no, this is the cheapest orange one, with one usb, so it’s a wifi dongle. my orange pi plus, with the onboard wifi, i managed to fry :-( cheers, danny > Cheers, > > Mat > > On 30 Oct 2016, at 14:07, Daniel Braniss wrote: > > hi, > between r30666 and r30808 i lost my wireless, s/r30666/r306333/ and s/r30808/r308087/ > so reading UPDATE clarified why, I also did a mergemaster so now devd > et.all. seem to be in sync, > but now devd complains that if_rtwn_usb depends on rtwm and there is no > rtwn, instead there are > several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko > > this is what the old urtwn has to say: > ... > Starting devd. > wlan: <802.11 Link Layer> > urtwn0 on uhub1 > urtwn0: on usbus0 > urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R > urtwn0: enabling 11n > urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps > urtwn0: 1T1R > urtwn0: 11ng MCS 20MHz > urtwn0: MCS 0-7: 6.5Mbps - 65Mbps > > please help > > thanks, > danny > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-wirel...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: urtwm -> rtwm
Hi! rtwn_usb(4) depends on rtwn(4) module; you can try to 1) add them to the kernel config; 2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables 3) compile / install them manually P.S. There is no 'rtwm' module in the tree; what is the exact error message where it was? the problem was that if_rtwn.ko was not compiled! all the others where, i.e. if_rtwn_[pci,usb].ko. I added all of them to the config, and now it seems to work so the problem is that the loadable module if_rtwn.ko is NOT compiled by default, while all the others are, what is the magic to have it compiled? From my experience you always have to specify all modules and the modules they depend on. I for example had to specify this for zfs support in the config file: makeoptions MODULES_OVERRIDE="zfs opensolaris acl_nfs4" I actually only wanted zfs, which depends on opensolaris which then again depends on acl_nfs4 (probably because I sepcified nfs4 support in the config file) I only found out after a few tries. It's really not ideal, that module dependencies are not resolved. But once you know about it, you can live with it :-) BTW, I tried this on RPI2, and now will try on an orangepi one. Is that the SDIO based internal WiFi? Let me know if it works! Cheers, Mat On 30 Oct 2016, at 14:07, Daniel Braniss wrote: hi, between r30666 and r30808 i lost my wireless, s/r30666/r306333/ and s/r30808/r308087/ so reading UPDATE clarified why, I also did a mergemaster so now devd et.all. seem to be in sync, but now devd complains that if_rtwn_usb depends on rtwm and there is no rtwn, instead there are several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko this is what the old urtwn has to say: ... Starting devd. wlan: <802.11 Link Layer> urtwn0 on uhub1 urtwn0: on usbus0 urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R urtwn0: enabling 11n urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps urtwn0: 1T1R urtwn0: 11ng MCS 20MHz urtwn0: MCS 0-7: 6.5Mbps - 65Mbps please help thanks, danny ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-wirel...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
