Re: rs, jot: missing headers
On Sat, Apr 12, 2014 at 7:47 AM, Ralph Siegler wrote: ... > So, let's see you successfully submit patches to *remove* those > non-2008.1 features and backwards compatibilities to .1 and even before, > and fix the collateral damage to the distro that the minus diffs cause. > I double-dog dare you. You're daring me to do something that I've been doing for years, and that the OpenBSD ports team *supports*, asking for our headers to be made cleaner. Ookay. Philip Guenther
Re: OpenBSD Foundation 2014 Fundraising Campaign.
> nobody [openbsd.as.a.desk...@gmail.com] wrote: > > Hi all, > > > > - > > 1) > > If I search for "openbsdfoundation" on: > > > > - Facebook > > - Twitter > > - Youtube > > - Instagram > > - Flickr > > - Slideshare > > - etc.. > > > > I get ZERO results regarding the topic. > > > > I was thinking, maybe a superbowl commercial. Yikes, those things are expensive. To do that, someone would need to first setup a not-for-profit to fund the commercial, then the proceeds from the commercial can roll back to the proper software development funding foundation. Quick, someone register openbsdsuperbowlcommercialfoundation.org!
Re: OpenBSD Foundation 2014 Fundraising Campaign.
nobody [openbsd.as.a.desk...@gmail.com] wrote: > Hi all, > > - > 1) > If I search for "openbsdfoundation" on: > > - Facebook > - Twitter > - Youtube > - Instagram > - Flickr > - Slideshare > - etc.. > > I get ZERO results regarding the topic. > I was thinking, maybe a superbowl commercial.
Re: rs, jot: missing headers
On Sat, 12 Apr 2014 11:36:56 -0400, Kenneth Westerback wrote: > On 12 April 2014 10:47, Ralph Siegler wrote: >> On Fri, 11 Apr 2014 22:56:52 -0700, Philip Guenther wrote: >> >> Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind quarters but will compile and run code having those functions..which is better? >>> >>> Best for what? >> >> best for the particular example I gave. There are others, where system >> gets the POSIX stamp of approval by having .h functions from a list but >> doesn't actually implement them or just partially implements them. >> Just a part of the proofs that 100% POSIX chest-thumping is silly, that >> spec needs some spiffing up before it should be taken 100% seriously. >> >> OpenBSD doesn't strive to be the be-all and end-all of >>> UNIX-like OSes. We ain't realtime, and our threading and MP are still >>> both bad and ugly in many places, and we don't have lots of the flashy >>> bells that other OSes have. What we have a strong drive to incubate >>> better quality in ourselves and the entire software community by >>> exposing, >>> pushing on, and redirecting bad practices in software development. >> >> Yes, OpenBSD excels at clobbering code that does careless things ; my >> code, new and old, still runs fine on it, thanks. You left out >> emphasis on security, robustness and correctness. That's why I've been >> using and contributing money to OpenBSD project for 13+ years. >> >> >>> If you want an OS that has infinite backwards compat and offers all >>> the bells and whistles, look elsewhere. Those are both anathema to >>> OpenBSD and requests for them will be fruitless. >> >> I am not implying any desire for any other backwards compatible >> additions to the project. Because OpenBSD already has those! Has had >> them from day one, and there are good reasons for that. The one who is >> doing something fruitless is you. >> >> >> So, let's see you successfully submit patches to *remove* those >> non-2008.1 features and backwards compatibilities to .1 and even >> before, and fix the collateral damage to the distro that the minus >> diffs cause. I double-dog dare you. > > "the distro"? What the fuck is "the distro"? Has OpenBSD suddenly > morphed into Linux? that is merely slang for "The Distribution", the OpenBSD project itself certainly uses the longer phrase, and sorry if the slang shorter one connotates legions of marauding penguins to you. > > I recommend against 'double-dog' daring Philip about this (assuming your > goal to to prevent the changes) since he has complete freedom to commit > these changes whenever the mood strikes him. Just my way of pointing out that attempting 100% POSIX compliance would be extraordinarily difficult; the spec has grey areas, incomplete areas, vague areas (hence the silliness of holding it up as a golden benchmark), and would necessitate some drastic changes to the code (to say nothing of the ports). The cost in man-hours would be likely too high a price for six dozen (admittedly gifted) developers to pay; and the result would only be compliance subject to certain interpretations and caveats. There are legacy support in the code that makes the OS very useful and easier to port to, to remove them would have dire consequences to the user community. > > And on that day, many programs and libraries will know what it is to be > roasted in the depths of a POSIX specification. > > Ken
Re: rs, jot: missing headers
On 12 April 2014 10:47, Ralph Siegler wrote: > On Fri, 11 Apr 2014 22:56:52 -0700, Philip Guenther wrote: > > >>> Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind >>> quarters but will compile and run code having those >>> functions..which is better? >> >> Best for what? > > best for the particular example I gave. There are others, where system > gets the POSIX stamp of approval by having .h functions from a list but > doesn't actually implement them or just partially implements them. Just > a part of the proofs that 100% POSIX chest-thumping is silly, that spec > needs some spiffing up before it should be taken 100% seriously. > > OpenBSD doesn't strive to be the be-all and end-all of >> UNIX-like OSes. We ain't realtime, and our threading and MP are still >> both bad and ugly in many places, and we don't have lots of the flashy >> bells that other OSes have. What we have a strong drive to incubate >> better quality in ourselves and the entire software community by >> exposing, >> pushing on, and redirecting bad practices in software development. > > Yes, OpenBSD excels at clobbering code that does careless things ; my > code, new and old, still runs fine on it, thanks. You left out emphasis > on security, robustness and correctness. That's why I've been using and > contributing money to OpenBSD project for 13+ years. > >> >> If you want an OS that has infinite backwards compat and offers all the >> bells and whistles, look elsewhere. Those are both anathema to OpenBSD >> and requests for them will be fruitless. > > I am not implying any desire for any other backwards compatible additions > to the project. Because OpenBSD already has those! Has had them from > day one, and there are good reasons for that. The one who is doing > something fruitless is you. > > > So, let's see you successfully submit patches to *remove* those > non-2008.1 features and backwards compatibilities to .1 and even before, > and fix the collateral damage to the distro that the minus diffs cause. > I double-dog dare you. "the distro"? What the fuck is "the distro"? Has OpenBSD suddenly morphed into Linux? I recommend against 'double-dog' daring Philip about this (assuming your goal to to prevent the changes) since he has complete freedom to commit these changes whenever the mood strikes him. And on that day, many programs and libraries will know what it is to be roasted in the depths of a POSIX specification. Ken > >> >> >> Philip > >
Re: rs, jot: missing headers
On Fri, 11 Apr 2014 22:10:05 -0700, Philip Guenther wrote: > On Sat, 12 Apr 2014, Ralph Siegler wrote: >> > Well, starting with r1.54 [0], stdlib.h never declares getopt(). >> > However, I think the conversation could continue in spite of that. >> > I would expect "motivation" to be aggregated cost in the form: >> > * a significant amount of patched ports; >> > * a significant amount of affected port prospects; or * a significant >> > amount of patched user programs. >> > You happen to mention the last item. Are there other users interested >> > in this facet of source compatibility? >> > >> > Also, are there other possible costs? >> > >> > [0] >> > http://www.openbsd.org/cgi-bin/cvsweb/src/include/stdlib.h.diff? >> r1=1.53;r2=1.54;f=h >> >> You are mistaken, it was just defined in different place/way in same >> file, even 18 years ago it is found in OpenBSD in stdlib.h (as well as >> in unistd.h): > > Gotcha: you don't want to update a program to meet 18+ year old > standards. > Is your beef with OpenBSD? Or is it with POSIX for specifying in 1995 > that getopt() only be declared in unistd.h and not stdlib.h? > > >> It doesn't hurt anything to provide this backward compatibility > > It makes the header more complex and annoying to maintain, just to > support programs that haven't been updated for 18+ years. That's a > negative. Wrong, the stuff is already in the headers, no maintenance necessary. what would be HARD is to remove all the non-2008.1, and fix the breakages it would cause, then modify and add calls for the missing functionality, again without breaking anything. It would be much fun and entertainment to watch such an endeavor, I'll pop popcorn for that space opera series. > > You may find it interesting to see how long a source tree might work > without changes, but that's not of interest to OpenBSD. It's probably > of *negative* interest of OpenBSD, as adding "#include " is a > trivial cost to the person compiling said unmaintained program, and such > a program probably hasn't been scrutinized for the various sins of the > past like buffer and string handling, TOCTOU violations, etc. History > is neat to study, but living in it sucks. All BSD have much history in them, even with the fantastic evolution, fixes and improvements. > > > Philip
cpsw updates
This diff will properly initialize cpsw if uboot hasn't done so already. It
also adds support for 1000BaseT (RGMII) PHY found on some boards. Based heavily
on a netbsd diff. My BBB is out of comission so please test this and provide
feedback. Thanks.
diff -r 4d62a2f27093 -r 961793eb2b24 src/sys/arch/armv7/omap/if_cpsw.c
--- a/src/sys/arch/armv7/omap/if_cpsw.c Fri Apr 11 16:35:16 2014 -0400
+++ b/src/sys/arch/armv7/omap/if_cpsw.c Sat Apr 12 06:23:19 2014 -0400
@@ -127,7 +127,7 @@
struct arpcomsc_ac;
struct mii_data sc_mii;
-
+ bool sc_phy_has_1000t;
struct cpsw_ring_data *sc_rdp;
volatile u_int sc_txnext;
volatile u_int sc_txhead;
@@ -174,6 +174,10 @@
intcpsw_txintr(void *);
intcpsw_miscintr(void *);
+#defineCPSW_MAX_ALE_ENTRIES1024
+
+static int cpsw_ale_update_addresses(struct cpsw_softc *, int purge);
+
void cpsw_get_mac_addr(struct cpsw_softc *);
struct cfattach cpsw_ca = {
@@ -298,6 +302,18 @@
}
}
+static bool
+cpsw_phy_has_1000t(struct cpsw_softc * const sc)
+{
+ struct ifmedia_entry *ifm;
+
+ TAILQ_FOREACH(ifm, &sc->sc_mii.mii_media.ifm_list, ifm_list) {
+ if (IFM_SUBTYPE(ifm->ifm_media) == IFM_1000_T)
+ return true;
+ }
+ return false;
+}
+
void
cpsw_attach(struct device *parent, struct device *self, void *aux)
{
@@ -405,14 +421,29 @@
ifmedia_init(&sc->sc_mii.mii_media, 0, cpsw_mediachange,
cpsw_mediastatus);
+
+ /* Initialize MDIO */
+ cpsw_write_4(sc, MDIOCONTROL, MDIOCTL_ENABLE | MDIOCTL_FAULTENB |
MDIOCTL_CLKDIV(0xff));
+ /* Clear ALE */
+ cpsw_write_4(sc, CPSW_ALE_CONTROL, ALECTL_CLEAR_TABLE);
+
mii_attach(self, &sc->sc_mii, 0x,
MII_PHY_ANY, MII_OFFSET_ANY, 0);
if (LIST_FIRST(&sc->sc_mii.mii_phys) == NULL) {
printf("no PHY found!\n");
+ sc->sc_phy_has_1000t = false;
ifmedia_add(&sc->sc_mii.mii_media,
IFM_ETHER|IFM_MANUAL, 0, NULL);
ifmedia_set(&sc->sc_mii.mii_media, IFM_ETHER|IFM_MANUAL);
} else {
+ sc->sc_phy_has_1000t = cpsw_phy_has_1000t(sc);
+ if (sc->sc_phy_has_1000t) {
+ printf("1000baseT PHY found. setting RGMII Mode\n");
+ /* Select the Interface RGMII Mode in the Control
Module */
+ sitara_cm_reg_write_4(CPSW_GMII_SEL,
+ GMIISEL_GMII2_SEL(RGMII_MODE) |
GMIISEL_GMII1_SEL(RGMII_MODE));
+ }
+
ifmedia_set(&sc->sc_mii.mii_media, IFM_ETHER|IFM_AUTO);
}
@@ -781,6 +812,8 @@
/* Reset and init Sliver port 1 and 2 */
for (i = 0; i < 2; i++) {
+ uint32_t macctl;
+
/* Reset */
cpsw_write_4(sc, CPSW_SL_SOFT_RESET(i), 1);
while(cpsw_read_4(sc, CPSW_SL_SOFT_RESET(i)) & 1);
@@ -795,10 +828,12 @@
cpsw_write_4(sc, CPSW_PORT_P_SA_LO(i+1),
ac->ac_enaddr[4] | (ac->ac_enaddr[5] << 8));
- /* Set MACCONTROL for ports 0,1: FULLDUPLEX(1), GMII_EN(5),
- IFCTL_A(15), IFCTL_B(16) FIXME */
- cpsw_write_4(sc, CPSW_SL_MACCONTROL(i),
- 1 | (1<<5) | (1<<15) | (1<<16));
+ /* Set MACCONTROL for ports 0,1 */
+ macctl = SLMACCTL_FULLDUPLEX | SLMACCTL_GMII_EN |
+ SLMACCTL_IFCTL_A;
+ if (sc->sc_phy_has_1000t)
+ macctl |= SLMACCTL_GIG;
+ cpsw_write_4(sc, CPSW_SL_MACCONTROL(i), macctl);
/* Set ALE port to forwarding(3) */
cpsw_write_4(sc, CPSW_ALE_PORTCTL(i+1), 3);
@@ -811,6 +846,9 @@
/* Set ALE port to forwarding(3) */
cpsw_write_4(sc, CPSW_ALE_PORTCTL(0), 3);
+ /* Initialize addrs */
+ cpsw_ale_update_addresses(sc, 1);
+
cpsw_write_4(sc, CPSW_SS_PTYPE, 0);
cpsw_write_4(sc, CPSW_SS_STAT_PORT_EN, 7);
@@ -1220,3 +1258,191 @@
return 1;
}
+/*
+ * ALE support routines.
+ */
+
+static void
+cpsw_ale_entry_init(uint32_t *ale_entry)
+{
+ ale_entry[0] = ale_entry[1] = ale_entry[2] = 0;
+}
+
+static void
+cpsw_ale_entry_set_mac(uint32_t *ale_entry, const uint8_t *mac)
+{
+ ale_entry[0] = mac[2] << 24 | mac[3] << 16 | mac[4] << 8 | mac[5];
+ ale_entry[1] = mac[0] << 8 | mac[1];
+}
+
+static void
+cpsw_ale_entry_set_bcast_mac(uint32_t *ale_entry)
+{
+ ale_entry[0] = 0x;
+ ale_entry[1] = 0x;
+}
+
+static void
+cpsw_ale_entry_set(uint32_t *ale_entry, ale_entry_filed_t field, uint32_t val)
+{
+ /* Entry type[61:60] is addr entry(1), Mcast fwd state[63:62] is fw(3)*/
+ switch (field) {
+ case ALE_ENTRY_TYPE:
+ /* [61:60] */
+ ale_entry[1] |= (val & 0x3) << 28;
+
Re: rs, jot: missing headers
On Fri, 11 Apr 2014 22:56:52 -0700, Philip Guenther wrote: >> Meanwhile, OpenBSD doesn't have the 100% 2008.1 beef stamp on its hind >> quarters but will compile and run code having those >> functions..which is better? > > Best for what? best for the particular example I gave. There are others, where system gets the POSIX stamp of approval by having .h functions from a list but doesn't actually implement them or just partially implements them. Just a part of the proofs that 100% POSIX chest-thumping is silly, that spec needs some spiffing up before it should be taken 100% seriously. OpenBSD doesn't strive to be the be-all and end-all of > UNIX-like OSes. We ain't realtime, and our threading and MP are still > both bad and ugly in many places, and we don't have lots of the flashy > bells that other OSes have. What we have a strong drive to incubate > better quality in ourselves and the entire software community by > exposing, > pushing on, and redirecting bad practices in software development. Yes, OpenBSD excels at clobbering code that does careless things ; my code, new and old, still runs fine on it, thanks. You left out emphasis on security, robustness and correctness. That's why I've been using and contributing money to OpenBSD project for 13+ years. > > If you want an OS that has infinite backwards compat and offers all the > bells and whistles, look elsewhere. Those are both anathema to OpenBSD > and requests for them will be fruitless. I am not implying any desire for any other backwards compatible additions to the project. Because OpenBSD already has those! Has had them from day one, and there are good reasons for that. The one who is doing something fruitless is you. So, let's see you successfully submit patches to *remove* those non-2008.1 features and backwards compatibilities to .1 and even before, and fix the collateral damage to the distro that the minus diffs cause. I double-dog dare you. > > > Philip
