From owner-freebsd-hackers@freebsd.org Sun Mar 18 04:46:57 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49F2BF5DFE5 for ; Sun, 18 Mar 2018 04:46:57 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CBBFC7E4F6 for ; Sun, 18 Mar 2018 04:46:56 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-ot0-x22d.google.com with SMTP id y11-v6so14258976otg.0 for ; Sat, 17 Mar 2018 21:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dNIRUXVq3eqo8j7jW+dKstIWC93Eeqj68kXeUq4QMzM=; b=g1Lvw9mZa+bft5BFpwSJ42ppmtK5LhXDNvCL0KNEwF9HlqA7/08DwNW8Ncgn3//6Mq ZYC8qvtW7BTiXQ0N1ZrC9A68EOisl2HOEmA3XS5FWTdw7aBQXNaKUxnVkXx6Q3/GB9KL Ts5G+ruwpMISVMqX0sO69OmlOZGXxViMZ5DU9p6d0bk6xXnkrmqMtmUm7asNdb7hj+/2 jW09pupaDnK/JMb0HEX93ZHOJdSK+VFg6IVtARVdFphgEDelZtO8n0tbA7kKsJCPEIii tlPRlF7OPZCfv/cC+52EyUzidp75pRh/VZXtgbHnQMdKfOA6yqcJZl8Vb3IFI8y+Uqje /wjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dNIRUXVq3eqo8j7jW+dKstIWC93Eeqj68kXeUq4QMzM=; b=OEcENreYZwNq1+DOQ2FmFicmzlf7b7S7VyNsfpwnb2lfT6ONNYBhF9zXyFQaQxuFxE 58+MvQJUalp/2SQNpKCZLAHi7TNyTxY1kpvHdjZQaq4cqXigR2O1pX0QFwY44sqBGwGA P7C4XV8SeKjGBvsyW9TCBGJ0ksfmIKrZaubKRFsn/gCPcHtGgmbGhV8/+RTGPdbYEXwi j0F43TKFWcLkxmH+gmk+f+bfINEXXzl6ueeXTc8EXQVc1ic4DxEN35sBqGn4XBmelYWE PrnLVxAoPe2lRKAIOXFDwrustZTCqnodwbdIK7zXc9fM1PxMsi0IAwATcEkHNRaFKJT9 YwYw== X-Gm-Message-State: AElRT7GgCsrhU6cVfph3y2GS/iLlCm24Y7XXwQqLPGMABdegKUykpZVJ htA2A/n59TrMxQlOn35xa4ZC/d7NKhMABlhYEbzWIQ== X-Google-Smtp-Source: AG47ELsnMICIcVo+BiBbbc+BCtz43WMWHpCjLwHUtqWuVxNlvu9vByn7qpA3R2T+Q27SGN0dEc/1w3vpQ290qEk/0jE= X-Received: by 2002:a9d:747:: with SMTP id 65-v6mr4708550ote.219.1521348416016; Sat, 17 Mar 2018 21:46:56 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:4206:0:0:0:0:0 with HTTP; Sat, 17 Mar 2018 21:46:15 -0700 (PDT) From: Lee D Date: Sun, 18 Mar 2018 00:46:15 -0400 Message-ID: Subject: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 04:46:57 -0000 Hi Everyone, I am back to working on my Zynq I2C and M41T82 RTC chip drivers. I am still using 11.0.1. It turns out that the Zynq I2C hardware is buggy and it doesn't really fit in with the FreeBSD paradigm of issuing discrete bus transactions (start, stop, etc.) I am trying to work around this by writing my own version of iicbus_transfer_gen(), copied from src/sys/dev/iicbus/iiconf.c My question is, where is iicbus_get_nostop() defined? I can't seem to find it with grep. "nostop" seems to get turned on at some point, and while I could just ignore it, I'd like to know where and how it is happening. Thanks, Lee From owner-freebsd-hackers@freebsd.org Sun Mar 18 14:30:32 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 681CDF58311 for ; Sun, 18 Mar 2018 14:30:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E2BE173A88 for ; Sun, 18 Mar 2018 14:30:31 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e5d427a1-2ab8-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e5d427a1-2ab8-11e8-91c6-33ffc249f3e8; Sun, 18 Mar 2018 14:30:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2IEUKLH034326; Sun, 18 Mar 2018 08:30:20 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521383420.99081.87.camel@freebsd.org> Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? From: Ian Lepore To: Lee D , FreeBSD Hackers Date: Sun, 18 Mar 2018 08:30:20 -0600 In-Reply-To: References: Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2018 14:30:32 -0000 On Sun, 2018-03-18 at 00:46 -0400, Lee D wrote: > Hi Everyone, > > I am back to working on my Zynq I2C and M41T82 RTC chip drivers.I am > still using 11.0.1. > > It turns out that the Zynq I2C hardware is buggy and it doesn't really > fit in with the FreeBSD paradigm of issuing discrete bus transactions > (start, stop, etc.) > > I am trying to work around this by writing my own version of > iicbus_transfer_gen(), copied from src/sys/dev/iicbus/iiconf.c > > My question is, where is iicbus_get_nostop() defined?I can't seem to > find it with grep. > > "nostop" seems to get turned on at some point, and while I could just > ignore it, I'd like to know where and how it is happening. > > Thanks, > > Lee Nostop is an ivar of the child device, so iicbus_get_nostop() is formed by the IICBUS_ACCESSOR macro in iicbus.h. Now for the bad news: don't use it. It doesn't work. It's 100% a bug in the code that maybe kinda-sorta seemed to work for whoever added it, because accidentally the right garbage was on the stack in the local nostop var. The generic transfer code doesn't check that the accessor failed so it ends up using stack garbage for nostop. The reason there's g'teed to be no such ivar is because the code is asking the wrong device, and it doesn't even have a handle to the right child device to get the info it wants. So the bottom line is, write your transfer routine to work however it has to work. That might mean ignoring the stop/nostop flags and just doing whatever your hardware does. Like if a write transaction is handled by the hardware by putting the slave address and the offse- within-slave values into registers and it does a write of the offset then a read from the slave and you get no control over whether it does that as two transactions or as 1 transaction with a repeat-start between the read and write, then just silently do it that way. I had forgotten about the nostop mess, which I discovered some time last year. It really needs to be fixed the right way, which is to remove the nostop hack, remove all uses of the NOSTOP flag everywhere in the code, and make the default behavior that all back-to-back operations in the same array of cmds handed to a single transfer call have implicit repeat-start behavior when changing slave or direction. We could add a specific STOP flag to force a stop/start between two commands, but even that's not really needed. The only example of a transfer-only driver I know of offhand is the rpi driver (arm/broadcom/bcm2835/bcm2835_bsc.c). Unfortunately, bugs in the rpi silicon complicate the code and make it a messy example. -- Ian From owner-freebsd-hackers@freebsd.org Mon Mar 19 00:26:25 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 580ACF613FA for ; Mon, 19 Mar 2018 00:26:25 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CE86C6F486 for ; Mon, 19 Mar 2018 00:26:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: by mailman.ysv.freebsd.org (Postfix) id 92B6AF613F8; Mon, 19 Mar 2018 00:26:24 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70CABF613F7 for ; Mon, 19 Mar 2018 00:26:24 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [198.144.209.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFF066F484 for ; Mon, 19 Mar 2018 00:26:23 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.15.2/8.15.2) with ESMTP id w2J0QKBo005273 for ; Mon, 19 Mar 2018 00:26:20 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.15.2/8.15.2/Submit) id w2J0QKrc005272 for hackers@freebsd.org; Sun, 18 Mar 2018 17:26:20 -0700 (PDT) (envelope-from david) Date: Sun, 18 Mar 2018 17:26:20 -0700 From: David Wolfskill To: hackers@freebsd.org Subject: Just HOW many buttons did that mouse claim to have??!? Message-ID: <20180319002620.GC1233@albert.catwhisker.org> Reply-To: hackers@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kVXhAStRUZ/+rrGn" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2018 00:26:25 -0000 --kVXhAStRUZ/+rrGn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The laptop I've been using for the last few years has served me well, but its warranty has run out, and I cycle in SF Bay area traffic as part of my normal commute, so I thought it would be best to get a newer machine (that's under warranty). I wrote up a description of the older machine (a Dell Precision M4800); one may read it at . The machine I recently acquired is a Dell Precision 7520; in many respects, it is quite similar. One rather stark difference in behavior, though, is that -- under FreeBSD -- the built-in mouse/trackpad/trackpoint of the 7520 appears to be completely non-functional. (If I plug in a USB mouse, that works Just Fine.) Oh -- the below is all done under head/amd64 @r331083. I had written (to mobile@) about this, and received a couple of hints; in pursuing those, I found some things that seem curious to me. After re-reading psm(4), I was "inspired" to augment my kernel configuration file with: | # For debugging the mouse/trackpad/touchpad on the Dell Precision 7520 | options PSM_DEBUG=3D2 After some poking around, I also sprinkled a few additional VLOG() invocations in src/sys/dev/atkbdc/psm.c, and stuck a "-v" in /boot.config. Here's an excerpt from a verbose dmesg.boot from the M4800: psm0: unable to allocate IRQ random: harvesting attach, 8 bytes (4 bits) from atkbdc0 psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 00 00 14 psm: status 00 00 14 psm: status 73 03 0a psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 53 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00004000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 And here is a similar excerpt (but without the additional debug level or VLOG() invocations) from the 7520: psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 64 02 psm: status 00 64 00 psm: status 00 64 03 psm: status 00 64 03 psm: data 00 00 00 psm: status 00 14 00 psm: status 00 14 00 psm: status 00 64 02 psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 52 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 100 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 Now, there's a lot of similarity... but psm(4) claims that the M4800 has "2 buttons" (which is at least incomplete, as it actually has 2 sets of 3 buttons each, but that's not critical -- after all, it works). But the 7520 claims to have "100 buttons" -- and that seems... a bit ambitious: it actually also has 2 sets of 3 buttons each. Now, I realize that 0x64 =3D=3D 100, so I suspected that the apparent change in the ordering of some the status values might be relevant. So here's what I see for the 7520 with additional debugging: psm0: unable to allocate IRQ random: harvesting attach, 8 bytes (4 bits) from atkbdc0 psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: ENABLE_DEV return code:00fa psm: DISABLE_DEV return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 64 02 psm: SEND_DEV_ID return code:00fa psm: device ID: 0000 In get_mouse_buttons() psm: SET_RESOLUTION (0) 00fa get_mouse_buttons(): set_mouse_resolution() OK psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 64 00 psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 64 03 psm: SET_RESOLUTION (3) 00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 64 03 [There's more later, but this is the point where get_mouse_buttons() has made a determination....] So... for the M4800, get_mouse_buttons() had received the status array [00 03 64], and returned element [1], which has a value of 0x03. But for the 7520, the reeceived status array is [00 64 03], and it (dutifully?) returns element 1, which is 0x64 -- or "100" in base 10. I can't help but think that either the hardware/firmware/ACPI/... is confused, and returning bytes in a sequence that wasn't expected, or that psm(4) is missing something to tell it that it should be interpreting things differently (e.g., returning element 2 for this hardware). More from the verbose dmesg.boot: psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (3) 00fa psm: SET_RESOLUTION (1) 00fa psm: SET_RESOLUTION (2) 00fa psm: SET_RESOLUTION (3) 00fa psm: SEND_AUX_DEV_DATA return code:00fa psm: data 00 00 00 psm: SET_SAMPLING_RATE (200) 00fa psm: SET_SAMPLING_RATE (100) 00fa =2E..[there's lots more where that came from]... psm: device ID: 0000 synaptics: BEGIN init psm: SET_SCALING11 return code:00fa psm: SET_RESOLUTION (0) 00fa =2E.. psm: status 00 14 00 elantech: BEGIN init psm: SET_SCALING11 return code:00fa psm: SET_SCALING11 return code:00fa =2E.. psm: device ID: 0000 GlidePoint: BEGIN init psm: SET_SAMPLING_RATE (100) 00fa psm: SET_RESOLUTION (0) 00fa psm: SET_SCALING21 return code:00fa psm: SET_SCALING21 return code:00fa psm: SET_SCALING21 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 10 64 00 psm0: found GlidePoint psm: SET_RESOLUTION (100) 00fa psm: SET_SAMPLING_RATE (2) 00fa psm: SET_SCALING11 return code:00fa psm: SEND_AUX_DEV_STATUS return code:00fa psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 6 vector 52 =2E... So: Among other things, it appears that the number of buttons is determined in psm(4) before it (thinks it) knows what specific type of hardware this is. So I'm not seeing how I could teach psm(3) to make allowance for this (oddball?) hardware. And... Dell also offers the machine with some flavor of Ubuntu(?) pre-installed. So I suspect that some folks have figured out how to make this beastie work. (I bought mine reburbished; it didn't come with Ubuntu installed... and I wouldn't know how to get information like the above from that environment anyway.) (A correspondent over in mobile@ suggested snipping out the code that matches GlidePoint, allowing psm(4) to treat the device as a generic ps/2 mouse. I tried that, but saw no change in the behavior -- and looking over the psm(4) man page for flags I could set didn't turn up anything that was obvious to me.) Hints? Thanks! Peace, david --=20 David H. Wolfskill david@catwhisker.org Trump administration: victimizing the defrauded and supporting the fraudste= rs See http://www.catwhisker.org/~david/publickey.gpg for my public key. --kVXhAStRUZ/+rrGn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEzLfO+ReoAfQwZNd7FTnMQKBJ7hcFAlqvA6xfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEND QjdDRUY5MTdBODAxRjQzMDY0RDc3QjE1MzlDQzQwQTA0OUVFMTcACgkQFTnMQKBJ 7heewAf/Ss2YqzEjftmCaRR9il4RKZgtsdiUgNsfO/ZjleBlltrYGVLI+iZcdJJN B1DKbq7KcV/gsKtTZpyUsuRF1TBG0EGFcvCV6pqpsb8TL4mE9Il+NwrM7kX/UTKT wddE7WEFQcjHIDFomrXx6TSigusldsZyNa5mL1QUreuPXk74g3NdBjt5aIr/Gxbc Pqjd5rJjjdIwr1IwwkkFEdlpU4uO0JWpKhemsMBEnUD0cp554BEnHCBbb38TO8SK oS3QSzh/L7mxJXE1f8RExU1b6tpYhDIDna2dB5uMMtLz9ZSw8HNJ29MwVS70/xCj cuJqbgLC+X6TTLFnHnZWbsvyxH+M5Q== =Jniz -----END PGP SIGNATURE----- --kVXhAStRUZ/+rrGn-- From owner-freebsd-hackers@freebsd.org Tue Mar 20 22:14:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1EACF4F84B for ; Tue, 20 Mar 2018 22:14:28 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 416676B303 for ; Tue, 20 Mar 2018 22:14:28 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-io0-x229.google.com with SMTP id l12so4263447ioc.10 for ; Tue, 20 Mar 2018 15:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=snLdHyksS8pwxtKvUJ5cMthKbJ70RgSAPdMO8DLPnhs=; b=DrCja7ElF9UPQfrbOl/qWi3vTo9mITseiosJXvQLcAKnQQeg6MDE+DSUwzQwsO59Jm yegiNCA/Ak0ngb3o0le9pqRvdsqbAIGVk+JhdD8y1E/eRE0YlAyirBAzQG1G4/QUz5Hz zoe340lJb7hdy0m9B96jzaugcvmQdTrBK/YxLXpgfOMW2P6D8p/YMmpjs28qVfRQ1JeO OjnFkQ+Oku75y/ZqGo9b7UauRZi8vwsqcl64HIvFelH9bJSEx8Sjf85G6bpfDZfxFG3I hRFwGZBtrFYmGN0fppFyEJ3w9zegp0al/QiPJlVPFtD6FJOe98ttT760HGhVMUtk9Xr+ utnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=snLdHyksS8pwxtKvUJ5cMthKbJ70RgSAPdMO8DLPnhs=; b=miAcQY02HtUc3QiqhI85rx+BWq6AVYZlHQmuRavaXLVA2cF2HX5SV+lEcajCzZskmW l8L2ycozQr1MlYZtnHJsm+8GmTTdDXeefFTR00fHVIueGkvmHtyyPTZHfGwPQL+hCR7G AfguyUEZNb4uSMP9C7QSFMTKvzcyVtTRNmWCcnIR50DLWv3nYYzDorK0fNandXH0/iLq cUZVMkGss8Ra0ircunXKOY2xZ4O4UWfuv6Fwv+xVwWTWRdQfKzV7cEcKEeY+5UbOJGcD K8dshF4kgJnXyxGy66V8SBR5pwoZAfB6y4/YsxBDc/NCzk3RY78WDssmBIFMabZ7nlP3 KmcQ== X-Gm-Message-State: AElRT7E9PLcw+03inHUpRklw6Qmn121A0iatJbgyB08JATN8Y861uZ1w MyqSlWknbXYRYyMY0zL32USZqbBrJ+H4DPFN1w== X-Google-Smtp-Source: AG47ELuVE4JSVLdVPrjEqFH7qDwxMgjHWeN7Y3ug8j+OJirLStdd/WRxW+0DxBVdt2oG9PU2jCPp/5S8Jd+dZMeFaaw= X-Received: by 10.107.162.146 with SMTP id l140mr14334987ioe.39.1521584067038; Tue, 20 Mar 2018 15:14:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.192.139.243 with HTTP; Tue, 20 Mar 2018 15:14:26 -0700 (PDT) From: Zaphod Beeblebrox Date: Tue, 20 Mar 2018 18:14:26 -0400 Message-ID: Subject: Intel RST disk formats and cache drives. To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2018 22:14:28 -0000 I see, and have used, the geom_raid bits to support Intel "software" RAID systems, but the support is imperfect. I have a laptop that has a rotating disk and an msata disk (for cache). I would like to use unused space on the msata disk for an installation of FreeBSD. However, FreeBSD doesn't see the "label" that uses the msata disk as cache. To try and figure things out more, I labelled an extra partition in windows on the msata drive and then booted FreeBSD. FreeBSD sees the extra partition, but not the cache partition. On further examination, it seems the Intel scheme uses blocks at the "end" of the disk and presents windows with a smaller disk. This squares with the system "C" disk. FreeBSD sees the GPT partition as corrupt because the "backup" doesn't exist. It does, but it's not at the "end" of the disk as FreeBSD sees it. So... when using the Cache, the intel driver in windows uses this labelling scheme on both disks. Has anyone looked at supporting this? Would we modify the existing graid to eat these disks, or some part of gpart/glabel? It doesn't exactly fit as there are also configurations where you have a RAID1 with a solid state cache drive. Is it possible we can support these configurations (at least as labels) without supporting the cache semantics? From owner-freebsd-hackers@freebsd.org Wed Mar 21 04:34:43 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41D2BF69C72 for ; Wed, 21 Mar 2018 04:34:43 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BACF47B009 for ; Wed, 21 Mar 2018 04:34:42 +0000 (UTC) (envelope-from lakhanshiva@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id 23-v6so3294047oir.11 for ; Tue, 20 Mar 2018 21:34:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=r7Ig6tpBZaFhRpjhbN4EYHrOmvVP1yFe+jpF5RHMkEw=; b=uvgcbBwsEoFBkDhkPq71hdJ+Xd1wjyn9K3lEpnBnCy3iz3yEqFsDbvcphSmHjZrrgu l9SBwEj2+1cLUDxQNatO5xvLXC8lrpi0I0s/vMCC90XC7qz/guMcoRRWxd5/Sgq2ad3b MZ1oOMmwaHOYCNsM/Bd9UwKzsztapMtTav7t/nu42COgULG3O9kcfB7K2ueR2P7J2OrT ZS2MKrx2gjtT6u25DhADZ9yK5XEz4T5QP4Y8quy97Q4GgjrJ3v11FiXXdIf+5xbiHo3k W518yrRbVm2oohSLkuv+8qhwnTVbPcE41TZBsyP6JKY42PfBKTnv1sTsnZ8nNaOeNf0e x9Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=r7Ig6tpBZaFhRpjhbN4EYHrOmvVP1yFe+jpF5RHMkEw=; b=rr2aEmSPmzjO52qKW5ZyINHlo+/Eou0YHZ/9je+7J2jJ6qChJQwSJPLuGsYi/XnuPE dDAGoyYm+wQQlNnKfYMnzubyQpT5l+UKG2mkk9Om+xckpKmAKejT4YneLRTr5i53Geu4 HFRcdYKuR+TdbzMlnX+tuAcctqWlPqxaXMplHZQ8nAgpIdUfWOMsdwCpFb7uZak+tE1+ vhbrImUAosgbWUYNIriQD3N+q8ejNunPFMvtMuzsV5ENiMIUAkdFG0iItwT87tWW2vku dSg5P67zhVckXBGvR4dN+pn8aknPIEkLRIVPcGtUwfS3oRrH9jjnEuxLUcUI+mgsIXXW fQnw== X-Gm-Message-State: AElRT7FXF8hAEm2bu3vwylaZJSwX4bHxa2ffsnud3jhnWM/lFQeL04g/ 9rYhQitKleI7W3/VxKMwS/0xKRsmOKqTUBPTzs1If7Us X-Google-Smtp-Source: AG47ELvOoGG7+tBVzP5QTm9T0MEcmhx77emetXsxpddObGzb7+YdW5w2NzpJBUyhRLmB8E4F3RB0ZuV00OpODvgwtk8= X-Received: by 10.202.9.6 with SMTP id 6mr11637580oij.91.1521606881885; Tue, 20 Mar 2018 21:34:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:3be1:0:0:0:0:0 with HTTP; Tue, 20 Mar 2018 21:34:41 -0700 (PDT) From: Lakhan Shiva Date: Wed, 21 Mar 2018 10:04:41 +0530 Message-ID: Subject: [GSOC] Convert all PCI driver attachments to be table driven and mark with PNP_INFO To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2018 04:34:43 -0000 Hi Everyone! My name is Lakhan Kamireddy. I am a second year graduate student at University of Colorado Boulder. I am interested in the project to "Convert all PCI driver attachments to be table driven and mark with PNP_INFO" A little bio about me: I have a BE degree in Electrical and Electronics Engineering from a reputed national institute in India. I am more into Embedded Systems, Firmware programming and VLSI D&V. Last year summer, I was an intern at Google, Sunnyvale office in Califronia,as a Hardware Engineering intern and developed a Formal Verification library (SystemVerilog and Perl) which falls under RTL design and Verification domain. I have pursued some graduate level courses like Embedded System Design, Internet of Things Firmware, Logic Synthesis and Optimization, Computer Aided Verification(Formal Verification) at the University of Colorado Boulder in the past years . I think this would be a great project and would like to come up with a proposal for this. Kindly get in touch if you have any more ideas or tasks to get started. Cheers! Lakhan Kamireddy From owner-freebsd-hackers@freebsd.org Thu Mar 22 15:16:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4AC09F4D193 for ; Thu, 22 Mar 2018 15:16:38 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D964379FD1 for ; Thu, 22 Mar 2018 15:16:37 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 9DC8FF4D18C; Thu, 22 Mar 2018 15:16:37 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C765F4D18B for ; Thu, 22 Mar 2018 15:16:37 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0A0BD79FCF for ; Thu, 22 Mar 2018 15:16:37 +0000 (UTC) (envelope-from rank1seeker@gmail.com) Received: by mail-wr0-x22f.google.com with SMTP id c24so9079347wrc.6 for ; Thu, 22 Mar 2018 08:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=SwSgN6oc7U6dN9tmPzHNaXne42MsRF+Qnn6AUKnnL4M=; b=NpnNvshwLvMQXVi8luJhkmD2hO/O4TkYgcTjAGE272kT/8kiNq8rfp8N5B0rvbVbf5 uIOkTHylXfNGMCAuzrzeqL2uLvFAtuAbtFR+Av5OG1xcUMiNFiQXROUe86EV3OUqXL+r GRTdxcVe7Stz+6XvStvVvQdleyD3o3my8MsJ47cWDrZfOpvVuYEY1fbKC3Ahi4RY56AQ MwZmOQWT7Q4yiLZANeOyzXcXOdv3V383aJrBMUy9XvE3wrUxxooO5YjRfV3I6LdVj/pU P3PLCiu2PF2i3y/k5DwhEtqc7FxtztAmnbo9ytn4uwrmjWrhZv0HtKSahnRAoaguC5tx AYyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-transfer-encoding; bh=SwSgN6oc7U6dN9tmPzHNaXne42MsRF+Qnn6AUKnnL4M=; b=KswT9nuaXlHDKbyEo2K3fVAV1O1Zo2ijmD8UVeWzJecbGt8tcHhsTOXgIBOYWQUZaA UDQCLtEwznvRECM17wA3u9q//r4pV3YO02ClVBfnaTlj7u+0RmJYqY5wtiBC3pQkrLKv dWiUIvGs3wWQqWIPJBWglygvXNngmFWCByvO/ibDir6Br8hnKgiLDOSRSlCkVNLe4hyg UoW5T6D2S2S5ZriGlB2DbzsjqpauZcwQ4rL7Eg89F4hxKB4wNH94yBfpimyQoijzSv2L RS7YfdCzLFipy3AS+7mOOPzQsWoLtKkf9Wr45rxJvIJalRZRJvtGdsCT0fPHlf6UjlSi eJwQ== X-Gm-Message-State: AElRT7GIZEFdLU8NtBSKCMVgsnPTQZPIBmMLn9+FjAfZW9/PZyudgu1m glZNVPs1sSKMeSDS6tWK056kmQ== X-Google-Smtp-Source: AG47ELtqXxkpNfQZXqO0VquD+oZGLUSQRhLUkAbfQhK7fy5xpYEf0fHIFYj3ESTcu1lPeO0fO8qnSg== X-Received: by 10.223.193.10 with SMTP id r10mr8799260wre.255.1521731794795; Thu, 22 Mar 2018 08:16:34 -0700 (PDT) Received: from localhost ([213.149.52.208]) by smtp.gmail.com with ESMTPSA id x128sm5465499wmg.20.2018.03.22.08.16.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Mar 2018 08:16:34 -0700 (PDT) Date: Thu, 22 Mar 2018 16:16:26 +0100 From: To: hackers@freebsd.org Subject: RFC2671: Extension Mechanisms for DNS (EDNS0) missing in 'man 5 resolv.conf' Message-ID: <20180322161626.0000576e@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 15:16:38 -0000 11.1 REL $ man 5 resolv.conf Doesn't have a description for edns0, under options and it is used in /etc/= resolv.conf I've also checked 11.1 STABLE & 12 CURRENT man pages. Nothing. Someone to add it ... Domagoj Smol=C4=8Di=C4=87 From owner-freebsd-hackers@freebsd.org Thu Mar 22 18:06:28 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CD50F5C839; Thu, 22 Mar 2018 18:06:28 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB16D82A57; Thu, 22 Mar 2018 18:06:27 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 30719212FC; Thu, 22 Mar 2018 14:06:27 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 22 Mar 2018 14:06:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=Qaut5wpHUXQybnEn2D3nXQE5yxEjffS0cgy6YPt1erU=; b=mSX/Cq4h GbFqzJ9EIHSIqO9+D0uxdZj4l8TwhvGWrA7xC/QaFAphFDLhvHd+74GkjJlteiNp wRIXVoCaNUGPn4Vp7wSYJknvfrcB8zARzdmisgz6kOFmI3UtSMI6ArO4sOASUPOh PDUJaUv5kzqXqjxe6WV5STBqW/NVzs5DXwzNDqLxU28WBZTS4jqUjttEIrqzh5bk CeILK8A0yLbsPY8xYhKXJnftSNYk4WQnBnb+RzUYakona4D+OunwqxEUMvduOIi9 oQ5cLhCLzS2c/JmGJJOVKO8dp1X1lnlEPXsFdPL7bluo1nMpFYcmiGFodRFqm2Iu ceVHKJ92JGJAyQ== X-ME-Sender: Received: from [10.57.105.205] (unknown [209.63.143.172]) by mail.messagingengine.com (Postfix) with ESMTPA id 7563F240DC; Thu, 22 Mar 2018 14:06:26 -0400 (EDT) From: Benno Rice Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Testing requested: Hybrid ISO/USB boot Message-Id: Date: Thu, 22 Mar 2018 11:06:24 -0700 To: FreeBSD Current , freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 18:06:28 -0000 Hello all! I=E2=80=99ve been working on the ability to create hybrid ISO/HDD boot = images for x86, a la what Linux systems do with ISOHYBRID. The general = theory seems to be that ISO images have a 32KB hunk of zeroes at the = front that they generally ignore so we=E2=80=99ll stick something in = there that can handle booting if need be. The cases generally break down = as follows: UEFI with CD: Boots using an EFI system partition embedded in the ISO = image. This loads loader, and so on. UEFI with HDD: Same as above as UEFI doesn=E2=80=99t really care what = the underlying medium is and it sees the ISO image. Legacy BIOS with CD: Boots using El Torrito as always. And now for the new part: Legacy BIOS with HDD: Sees a DOS MBR stuck in the 32KB at the front of = the ISO image. This MBR contains our MBR boot code, which sees an active = BSD slice containing a variant of our BSD boot code that reads from the = ISO filesystem instead of UFS. This finds loader in the ISO filesystem = and loads that. Loader has had support for reading ISO9660 images off = HDDs added. Everything continues normally after that. The review for these changes is here: https://reviews.freebsd.org/D14799 And a version of the standard =E2=80=9Cbootonly=E2=80=9D ISO image built = with these changes is here: https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz = I=E2=80=99ve tested this image under qemu and VMware under all four of = the BIOS/UEFI and CD/HDD combinations. I=E2=80=99ve also booted a system = build around an Asus X399 Prime motherboard with this dd=E2=80=99ed to a = USB stick. I=E2=80=99d love some testing on more systems, especially = things that are more likely to have more customized boot firmwares = (I=E2=80=99m thinking Dell, HP, etc). Many thanks, Benno.= From owner-freebsd-hackers@freebsd.org Thu Mar 22 19:08:00 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2970BF61F60 for ; Thu, 22 Mar 2018 19:08:00 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7874F85BFB for ; Thu, 22 Mar 2018 19:07:59 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 37F02F61F55; Thu, 22 Mar 2018 19:07:59 +0000 (UTC) Delivered-To: hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 25D93F61F54 for ; Thu, 22 Mar 2018 19:07:59 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 78E4285BF7 for ; Thu, 22 Mar 2018 19:07:58 +0000 (UTC) (envelope-from maxim.konovalov@gmail.com) Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.15.2/8.15.2) with ESMTP id w2MJ7tUX007355; Thu, 22 Mar 2018 22:07:55 +0300 (MSK) (envelope-from maxim.konovalov@gmail.com) Date: Thu, 22 Mar 2018 22:07:55 +0300 (MSK) From: Maxim Konovalov To: rank1seeker@gmail.com cc: hackers@freebsd.org Subject: Re: RFC2671: Extension Mechanisms for DNS (EDNS0) missing in 'man 5 resolv.conf' In-Reply-To: <20180322161626.0000576e@gmail.com> Message-ID: References: <20180322161626.0000576e@gmail.com> User-Agent: Alpine 2.20 (BSF 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Thu, 22 Mar 2018 19:36:28 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 19:08:00 -0000 On Thu, 22 Mar 2018, 16:16+0100, rank1seeker@gmail.com wrote: > 11.1 REL > > $ man 5 resolv.conf > Doesn't have a description for edns0, under options and it is used in /etc/resolv.conf > I've also checked 11.1 STABLE & 12 CURRENT man pages. Nothing. > > Someone to add it ... > RES_USE_EDNS0 is listed in resolver(3). -- Maxim Konovalov From owner-freebsd-hackers@freebsd.org Thu Mar 22 20:50:40 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 410D1F6AA78; Thu, 22 Mar 2018 20:50:40 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9FF4B6AEB6; Thu, 22 Mar 2018 20:50:39 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from scdbackup.webframe.org ([91.8.164.220]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MPUFR-1euyIQ298D-004iSk; Thu, 22 Mar 2018 21:50:31 +0100 Date: Thu, 22 Mar 2018 21:48:42 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: Re: Testing requested: Hybrid ISO/USB boot Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org References: In-Reply-To: Message-Id: <3373772881814803857@scdbackup.webframe.org> X-Provags-ID: V03:K0:X2ZuHSvTFNxirIwoIzSyYKMMq5K0YJ4wwI8UKwoxNR1XGIClnvj dhbogVGwnXVFgNJxOMxLHU//hh6Dz1q8AKcmTOXa9EvUCyzTmSsGrPtF6vaWcO5t4fjjz2L 25uxTAMKPE7ofu1IWH/pavoRY1KkpXTfbVOr+gN+bv7cjPHae+tlqEikRUOmHqw3KZXIXG0 s+lzRbF2DR5U3V/eWI60A== X-UI-Out-Filterresults: notjunk:1;V01:K0:6BNIbhrnOSU=:DV0JCJBopVIsUjCu1b1DD6 dtLU5n4ZumsjMr3J4S9H7c0DWnv0GigAHsNEWniN7MOYxG4wOQgVkmLirRHgoT/+xPE5FgVG2 0+0e2ghhxC6XYSUpE/xvCY1Crl6wicmSBtlyPGfcdqn9urTqV+tOBS6QffP93KwOXQrEJj6CA 4KvsQxbPdi6Z8lqazEst2Y8l1iIWQDjaVVWTSJv4kNkkirUns985riIYKy5QV9SU7Ijdn5Cla bXuIxopVBzyolDDOUytftrtV6lkCTNr1obW843VKONpNssX1xwzYn2nzTADTxzp50TPiRxQig dMw41nCiPzg8FAimRvCC5pFTUmeOANSJZ9P/j+vVQIphB/X7VonD+TMAd8og/yD8LOhR+yw8I hiPLqo1Q63MmX3L7TM3fpPDscalhXUyRSfro3+Txchw2Tzlfc9x31qcmGoQxEZn1ouassmxTu Y5qDlPWfwUBN4Z9s/K46CkNPsoZNugoOa76AZo9CR4W/44Gc4GYOQ4w2nckMjbvUoyMz60Jac fuj5u8SEvDwS7IuGu+1oy2Kn8nqGkT1enrUrEdWWIhsTfC6JEw37g6ekwRYHbIYHeIhV3JsfN FeJJelm3Uo/jBV4PUMyF8W/O7HQ6205Ai6JHB6+XAFyfjKoGfqSJjCmBRg+NUHg5Th/HpARaP 4O7jES1cec1iiggLvlvUTAS8k003L2fm3tjl0xQH+N2WdE9VVqiGlKj/Odo0zWbt8WXV1pmXk 4+3fqHEcrFF61RHALtIjFjW+QqrrKVFg9qnWKcdiEdf+Z76Z2O/CROEACSWRk2I3gPTfDeIVy BisfdEakiMFp6qnHMg17DxC5/nXrMretNtHNdLHg1I6CZdpoRE= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2018 20:50:40 -0000 Hi, Benno Rice wrote: > I’ve been working on the ability to create hybrid ISO/HDD boot images for > x86, a la what Linux systems do with ISOHYBRID. Waving friendly over the fence i feel entitled to give some neighbor's review. > The general theory seems to > be that ISO images have a 32KB hunk of zeroes at the front that they > generally ignore It is called System Area. ECMA-119, 6.2.1: "The System Area shall occupy the Logical Sectors with Logical Sector Numbers 0 to 15. The System Area shall be reserved for system use. Its content is not specified by this Standard." I collected some info about possible stuffings in https://dev.lovelyhq.com/libburnia/libisofs/raw/master/doc/boot_sectors.txt > Legacy BIOS with HDD: Sees a DOS MBR [...] sees an active BSD > slice containing a variant of our BSD boot code that reads from the ISO > [...] This finds loader in the ISO filesystem The isohybrid MBRs of SYSLINUX and GRUB expect to get patched-in the block address of the El Torito no-emulation boot image. To be done by SYSLINUX program "isohybrid", or xorrisofs options -isohybrid-mbr , --grub2-mbr. They try to stay small in order to create room for fancy partition tables GPT and APM. The MBR code even begins by a no-op area where one can put APM magic numbers which happen to be harmless x86 machine code. > https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz This does not look much like it addresses EFI. $ xorriso -indev hybrid-bootonly.iso -report_el_torito plain -report_system_area plain ... El Torito catalog : 19 1 El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 20 El Torito boot img : 2 BIOS y none 0x0000 0x00 1600 24 ... MBR partition table: N Status Type Start Blocks MBR partition : 1 0x80 0xa5 1 16 UEFI 2.4, 12.3.2.1, says about El Torito: "A Platform Id of 0xEF indicates an EFI System Partition." But entry 2 of this catalog is in a section with Platform Id 0x00 (x86 BIOS). If byte 38977 (decimal) was 0xef rather than 0x00, then it would be marked as an El Torito boot image for EFI. Further: This section begins at byte address 38976 by a byte value 0x90. According to El Torito specs this means that another section follows. Correct would be value 0x91, which announces the end of the catalog. (El Torito 1.0, Figure 4, Offset 0) On HDD, EFI looks for specially marked partitions in GPT or MBR partition table. In MBR partiton table it looks for a partition of type 0xEF. (UEFI 2.4, 5.2.2) In GPT it looks for Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. (UEFI 2.4, Table 19) So to mark the EFI partition, hybrid-bootonly.iso should have a MBR partition number 2 with type 0xEF, start at 512-byte block 24*2048/512 = 96, size 1600 blocks. (Strangely El Torito addresses by 2048-byte blocks but counts by 512-byte blocks. Size limit is 65535 blocks. But counts 0 and 1 mean to EFI "up to end of medium".) > I’ve tested this image under qemu OVMF/SDK-II/Tianocore is too tolerant with the EFI specs and with silently using BIOS boot equipment. Real iron EFIs insist much more in compliance. Have a nice day :) Thomas From owner-freebsd-hackers@freebsd.org Fri Mar 23 10:02:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DED9AF5ACE6 for ; Fri, 23 Mar 2018 10:02:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4686B6ADDE; Fri, 23 Mar 2018 10:02:52 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id v207-v6so17434194lfa.10; Fri, 23 Mar 2018 03:02:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bPwT2CEU/aUGablCLwFH9OQvSCUmn+MTE/aJyi65wk4=; b=OSEuoIrOh4NuQYQ6grUtBR9sIjar090BRKspMJkQGr6R/rQ7g7r/coQfTnRAPLtaF6 fWQqTr0yDea3FgCfi5wqq7j+JEJecgxVtNvSSitfheD+EAKWdF9jnkmPoIeCadCnREX9 CDZFJxq/Ubxol6iPOpyjA9IFHhnM98RzIjks1bwjTiYPZGGArCa7MeaT7oJa9M+lEEIv tkqMySg8DRC/NnuCXfrHCxxdTpdsE3SIaRDV9dQnGH23kImf46ySU41mmxU+hqQOpK0h F7P0m6r5/hSn2T+ERZzdKiFc0xd0mkmlukVv2ER3jUIqloXBtCLMcGZOCriiwe1pVMDS nlrA== X-Gm-Message-State: AElRT7ElOxxkQ0bv4lahBSDprWcJymOoMqfEEmM7swUV+QPCY9WENcCV 4JDJNnr+SLFAziF60zWf9oJvsGnF5vk= X-Google-Smtp-Source: AG47ELuVsK+H8tqy00KJnttmmPBKOZSv9DvOObp1WqaqlNQeOnzQDgVcToYvz5r6QORy6yTMcAoG+w== X-Received: by 2002:a19:e112:: with SMTP id y18-v6mr18497943lfg.102.1521798978394; Fri, 23 Mar 2018 02:56:18 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id o88-v6sm2132511lfg.34.2018.03.23.02.56.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 02:56:17 -0700 (PDT) From: Andriy Gapon Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? To: Ian Lepore , FreeBSD Hackers Cc: Konstantin Belousov References: <1521383420.99081.87.camel@freebsd.org> X-Mozilla-News-Host: news://news.gmane.org Message-ID: <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> Date: Fri, 23 Mar 2018 11:56:16 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1521383420.99081.87.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 10:02:53 -0000 On 18/03/2018 16:30, Ian Lepore wrote: > Now for the bad news:  don't use it.  It doesn't work.  It's 100% a bug > in the code that maybe kinda-sorta seemed to work for whoever added it, > because accidentally the right garbage was on the stack in the local > nostop var.  The generic transfer code doesn't check that the accessor > failed so it ends up using stack garbage for nostop.  The reason > there's g'teed to be no such ivar is because the code is asking the > wrong device, and it doesn't even have a handle to the right child > device to get the info it wants. Oh, indeed. I think that there never was an intention to make "nostop" a property of an i2c slave, a child of an iicbus device. I think that instead it was supposed to be a property of the iicbus's parent device, an actual i2c adapter driver. I guess that the reason that "nostop" became an ivar in iicbus was an incorrect understanding of how a "bit-banger" device (something implementing iicbb_if), iicbb device and iicbus device are connected. I think that I was among the reviewers and I probably had a bit of confusion back then. It seems that the only place where iicbus_get_nostop() is used is iicbus_transfer_gen(). iicbus_transfer_gen is used in several i2c drivers as an iicbus_transfer method. it's also used in iicbb, thinly wrapped by iicbb_transfer(). So, iicbus_get_nostop() actually translates to a call to BUS_READ_IVAR(parent, device, 1, &v) where I already substituted one for IICBUS_IVAR_NOSTOP. Here we can see that while the accessor functions lok quite nice they get expanded to generic calls without much context. So, whether that BUS_READ_IVAR() call succeeds and what value it gets depends on whether the parent bus defines an ivar with a value of 1 and what value that ivar might have for the driver device. Many buses define at least a couple of ivars. So, a return value of iicbus_get_nostop() could be consistent for a particular driver while still being arbitrary. But it can be a piece of stack garbage too, just as you said. The only place where iicbus_set_nostop() is used is intel_iicbb_attach(). In that case the ivar is "set" on a wrong device at all (the bit-banger, not iicbb). This definitely needs to be fixed / reworked. Perhaps nostop should become a new interface in iicbus_if and iicbb_if... -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Fri Mar 23 07:51:09 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C030F4FF94; Fri, 23 Mar 2018 07:51:09 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d7::103:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3CB85856EB; Fri, 23 Mar 2018 07:51:08 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:ad60:93d2:9211:833] (unknown [IPv6:2001:470:25:233:ad60:93d2:9211:833]) by host64.shmhost.net (Postfix) with ESMTPSA id A3E3B1653D9; Fri, 23 Mar 2018 08:50:59 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Testing requested: Hybrid ISO/USB boot From: Franco Fichtner In-Reply-To: Date: Fri, 23 Mar 2018 08:50:57 +0100 Cc: FreeBSD Current , freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Benno Rice X-Mailer: Apple Mail (2.3445.5.20) X-Virus-Scanned: clamav-milter 0.99.4 at host64.shmhost.net X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 23 Mar 2018 10:34:44 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 07:51:09 -0000 Hi Benno, > On 22. Mar 2018, at 7:06 PM, Benno Rice wrote: >=20 > I=E2=80=99ve been working on the ability to create hybrid ISO/HDD boot = images for x86, a la what Linux systems do with ISOHYBRID. The general = theory seems to be that ISO images have a 32KB hunk of zeroes at the = front that they generally ignore so we=E2=80=99ll stick something in = there that can handle booting if need be. The cases generally break down = as follows: Very cool! I ported the patch to 11.1-RELEASE and built an OPNsense image[1] based on the commands enclosed. (I'm not entirely sure if the porting was ok as there were quite a few challenges... but for the sake of testing...) Bhyve boot: ok VirtualBox boot: ok (when using extension .iso) APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader" and then escapes to "FreeBSD/x86 boot" etc. It's an UEFI style ISO[2] so not sure if this is problematic. I have other hardware to try and your image, but that's for later. Cheers, Franco -- [1] = https://pkg.opnsense.org/FreeBSD:11:amd64/snapshots/OPNsense-18.1.5-OpenSS= L-dvd-amd64.iso.bz2 [2] https://github.com/opnsense/tools/blob/master/build/dvd.sh From owner-freebsd-hackers@freebsd.org Fri Mar 23 08:01:53 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55D58F50F4D; Fri, 23 Mar 2018 08:01:53 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d7::103:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E0EBF85ED0; Fri, 23 Mar 2018 08:01:52 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from [IPv6:2001:470:25:233:ad60:93d2:9211:833] (unknown [IPv6:2001:470:25:233:ad60:93d2:9211:833]) by host64.shmhost.net (Postfix) with ESMTPSA id E1F6F1654AB; Fri, 23 Mar 2018 09:01:51 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Testing requested: Hybrid ISO/USB boot From: Franco Fichtner In-Reply-To: Date: Fri, 23 Mar 2018 09:01:50 +0100 Cc: FreeBSD Current , freebsd-hackers@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <6CA7676E-D558-4F9D-9613-C08D54D4C791@lastsummer.de> References: To: Benno Rice X-Mailer: Apple Mail (2.3445.5.20) X-Virus-Scanned: clamav-milter 0.99.4 at host64.shmhost.net X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 23 Mar 2018 10:34:52 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 08:01:53 -0000 Hi Benno, > On 23. Mar 2018, at 8:50 AM, Franco Fichtner wrote: > > APU1C boot: aborts with "Invalid partition" 3x, then "No /boot/loader" > and then escapes to "FreeBSD/x86 boot" etc. Small follow-up: the hybrid-bootonly.iso goes blank on this one due to no dual boot / serial settings. Cannot conform nor deny at this point. Cheers, Franco From owner-freebsd-hackers@freebsd.org Fri Mar 23 12:53:46 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1587AF69B29; Fri, 23 Mar 2018 12:53:46 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C894726BA; Fri, 23 Mar 2018 12:53:45 +0000 (UTC) (envelope-from maurizio1018@gmail.com) Received: by mail-pl0-x22e.google.com with SMTP id f23-v6so7360863plr.10; Fri, 23 Mar 2018 05:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Oqaad+Y/+sibLL9MTEBOrhG5wHbJ8FLVT+AOViTC994=; b=NZ3kN92YfWVtHzp92cY9xPMU0LG1YiCXbztO4+syTxjHeMMoXy9jZCc2oq21tLGl+n DmlxkYz6Wyw4qj0W1WFC7mzJMNFywGgFmILsyY/mVLTcnsla3y7FBpJ9+2lub4Lb/COT QJA1O1jwXL7Anf4gQA2KKiZF/Vo8bSXy252WHz9PNvPdir03BYTc/rKWjR8/PEP22zgP bC9yRy6M6PIUwAF3LpGbBKpIt6oBxybWP8/k1JUWU1RkFJtfK0tTIZP4Vs9KKJeeIRZ0 8+ire+qlmGIH1RCm9PmiqayT962LFtmxIuSGWO4SyTpZz303+pQkdX6Awk0LLXxZayEC ol5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Oqaad+Y/+sibLL9MTEBOrhG5wHbJ8FLVT+AOViTC994=; b=p9phs/cfVKPuGNLvlfK4tU/3hlziZ33Zschsop4Sdeh8MWyOhwPh7KS5uTeUaezKe6 t0IbYFzyvZ5dlsH5rrShQA9nydx6i0YsxWB8nS+F3vFecCXVzk0H1IFqMe4uw1l/JDsv uHiEyl2cautpcyUo/9fM3ipixU9BAMLREdV0r98abf9iyopH2/XpxyyJHeDKjZoIxuV6 V2T6/8NtcebhSPh3ZdPX2LUDgmv46FsVWsmQzJE3UJUMeZY1lAsZ/7iSNjEXl4oMAcgc MWQdXwuej7rPrmi8zijmtlH/AM0dwOMZsVPdknG2jI+q/M4STVO21AwEn1LCq8oEaY9f sEgg== X-Gm-Message-State: AElRT7Hbr9DwgS1Qrb7QEUDsX8/G6j2z/ZURCkhghA5i+AafqPutUFk+ E1Sob5GI5RhQh2kKr3KFoAVKUbN3QfU4pXtbuzs= X-Google-Smtp-Source: AG47ELtSicgn7dBziwK6ITsZdNRW+ZTN2C4997WRiZbsCQlGGrDUqy0MM0pA3lzo1ouLbswWVVaoRq/cRbIsHcAdRa0= X-Received: by 2002:a17:902:51ad:: with SMTP id y42-v6mr26335968plh.314.1521809624411; Fri, 23 Mar 2018 05:53:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.241.196 with HTTP; Fri, 23 Mar 2018 05:53:43 -0700 (PDT) In-Reply-To: References: From: Maurizio Vairani Date: Fri, 23 Mar 2018 13:53:43 +0100 Message-ID: Subject: Re: Testing requested: Hybrid ISO/USB boot To: Benno Rice Cc: FreeBSD Current , freebsd-hackers@freebsd.org X-Mailman-Approved-At: Fri, 23 Mar 2018 14:32:46 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 12:53:46 -0000 2018-03-22 19:06 GMT+01:00 Benno Rice : > Hello all! > > I=E2=80=99ve been working on the ability to create hybrid ISO/HDD boot im= ages for > x86, a la what Linux systems do with ISOHYBRID. The general theory seems = to > be that ISO images have a 32KB hunk of zeroes at the front that they > generally ignore so we=E2=80=99ll stick something in there that can handl= e booting > if need be. The cases generally break down as follows: > > UEFI with CD: Boots using an EFI system partition embedded in the ISO > image. This loads loader, and so on. > UEFI with HDD: Same as above as UEFI doesn=E2=80=99t really care what the > underlying medium is and it sees the ISO image. > Legacy BIOS with CD: Boots using El Torrito as always. > > And now for the new part: > > Legacy BIOS with HDD: Sees a DOS MBR stuck in the 32KB at the front of th= e > ISO image. This MBR contains our MBR boot code, which sees an active BSD > slice containing a variant of our BSD boot code that reads from the ISO > filesystem instead of UFS. This finds loader in the ISO filesystem and > loads that. Loader has had support for reading ISO9660 images off HDDs > added. Everything continues normally after that. > > The review for these changes is here: > > https://reviews.freebsd.org/D14799 > > And a version of the standard =E2=80=9Cbootonly=E2=80=9D ISO image built = with these > changes is here: > > https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz < > https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz> > > I=E2=80=99ve tested this image under qemu and VMware under all four of th= e > BIOS/UEFI and CD/HDD combinations. I=E2=80=99ve also booted a system buil= d around > an Asus X399 Prime motherboard with this dd=E2=80=99ed to a USB stick. I= =E2=80=99d love > some testing on more systems, especially things that are more likely to > have more customized boot firmwares (I=E2=80=99m thinking Dell, HP, etc). > > Many thanks, > Benno. > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " > Hi Benno, thank you for your work. On a Mac mini "Core i5" 2.3 (Mid-2011), booting via USB, it hangs very early, after writing: FreeBSD/x86 bootstrap loader, version 1.1 (Wed Mar 21 10:27:48 PDT 2018 benno@bobthe) Regards, Maurizio From owner-freebsd-hackers@freebsd.org Fri Mar 23 15:42:22 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6CA6CF528F8 for ; Fri, 23 Mar 2018 15:42:22 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: from mail-io0-f179.google.com (mail-io0-f179.google.com [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0C2607A721 for ; Fri, 23 Mar 2018 15:42:21 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: by mail-io0-f179.google.com with SMTP id o4so15647125iod.3 for ; Fri, 23 Mar 2018 08:42:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6zE8kPI7A0ALjnQfaiji4OMZVfQOAFZYdn0uXeBwZQE=; b=lAjM4+jbBjcuaNL7QG3yie34yMta7/p9TBTLc09kgt+ydjywfUHJ1tqJ2kdlsgloi2 JI6hEX+qovUyKrdlSQ+RUj6UhCIjuG6Sa+7Bonusaw35XKrKMBZkRAPUfrudpnbxIKm8 d52RRrQ6FMhvlIP8qriwBHR9LTaVK+GdLyYxzooAh6DF13SFFeN7B4HpVUHEkqVE/naK CsvwPDKiTWS+dZ4tQlITi9auDjmoX3al6DZ99rz6FcFiwjD9j0Pkd2a11z3Cw+t64aLu lsHn8gFVClkQCmGQJOAD1G70fIEEo3TGkpZkPXaukVgakHwAGtKn5E9DeuPjPhCHk6yW Qkwg== X-Gm-Message-State: AElRT7HsCGdgxncmRjBXqdaQLp9tVWI2FyjP4hsNfcL166YcE1uN/oLK a+uyVx2rKelccsfLVx9lJAdhBf52ECcMeM/Y/fPaeQ== X-Google-Smtp-Source: AIpwx4+gRc4EfO0ijL9aWWUZi0kcm/X5l3b35vgE3zhhvx6Vk+7glAeosYC0nJ3xepYg5dsgh/zTRpIug5OK/arFu6Q= X-Received: by 10.107.101.7 with SMTP id z7mr1675655iob.198.1521819735241; Fri, 23 Mar 2018 08:42:15 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?B?S2FtaWxhIFNvdcSNa292w6E=?= Date: Fri, 23 Mar 2018 15:42:04 +0000 Message-ID: Subject: Easiest way to get a small VM disk image? To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 15:42:22 -0000 Hello, I want to build an OpenNebula[1]-compatible VM image of FreeBSD 11.1. One requirement for my use case is that the image should initially be small (not as in "take up little physical space", but as in "the size of the virtual disk as visible in the VM should be small". Specifically, I want the virtual disk size to be no more than 3GB (which should not be a problem, as the default installation of FreeBSD takes a lot less than 3G). The VM images available in the official downloads have a virtual size of 20GB. Therefore I need to somehow build my own image (or shrink the existing ones). Here are the approaches I have thought about: - Create and partition an empty disk image, rsync the contents of the official image into it. Problems: AFAIK requires a FreeBSD host to build (in order to be able to create a UFS filesystem); requires juggling around with loopback mounts and such. Probably still the most feasible option, but I am not sure, which is why I'm asking. - Create an empty image, boot it in a VM and install from an installation ISO. Problem: not sure how to automate; might not get 1:1 parity with the official VM image - Somehow shrink the existing image. Problem: How? - Find out how the official images are built and do that with a smaller size. This is where this list comes in :-) Which (of these, or any other) is the easiest way to get a small image? Thanks a lot! Kamila [1] https://opennebula.org/ From owner-freebsd-hackers@freebsd.org Fri Mar 23 15:55:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30FC3F53E06 for ; Fri, 23 Mar 2018 15:55:38 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 902627B533 for ; Fri, 23 Mar 2018 15:55:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w2NFtYNB031889; Fri, 23 Mar 2018 08:55:34 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w2NFtYqw031888; Fri, 23 Mar 2018 08:55:34 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201803231555.w2NFtYqw031888@pdx.rh.CN85.dnsmgr.net> Subject: Re: Easiest way to get a small VM disk image? In-Reply-To: To: =?UTF-8?Q?Kamila_Sou=C4=8Dkov=C3=A1?= Date: Fri, 23 Mar 2018 08:55:34 -0700 (PDT) CC: "freebsd-hackers@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 15:55:38 -0000 > Hello, > > I want to build an OpenNebula[1]-compatible VM image of FreeBSD 11.1. One > requirement for my use case is that the image should initially be small > (not as in "take up little physical space", but as in "the size of the > virtual disk as visible in the VM should be small". Specifically, I want > the virtual disk size to be no more than 3GB (which should not be a > problem, as the default installation of FreeBSD takes a lot less than 3G). > > The VM images available in the official downloads have a virtual size of > 20GB. Therefore I need to somehow build my own image (or shrink the > existing ones). Here are the approaches I have thought about: > > - Create and partition an empty disk image, rsync the contents of the > official image into it. Problems: AFAIK requires a FreeBSD host to build > (in order to be able to create a UFS filesystem); requires juggling around > with loopback mounts and such. Probably still the most feasible option, but > I am not sure, which is why I'm asking. > - Create an empty image, boot it in a VM and install from an installation > ISO. Problem: not sure how to automate; might not get 1:1 parity with the > official VM image > - Somehow shrink the existing image. Problem: How? > - Find out how the official images are built and do that with a smaller > size. This is where this list comes in :-) > > Which (of these, or any other) is the easiest way to get a small image? > > Thanks a lot! Thought it still requires a FreeBSD host to do, somethink along the lines of: truncate -s 2G NEW_FreeBSD_vm_image mdconfig -f OFFICIAL_FreeBSD_vm_image -u 100 mdconfig -f NEW_FreeBSD_vm_image -u 101 #You have to fdisk, bsdlabale and newfs /dev/md101 here to your needs mkdir /tmp/output mount /dev/md101s1 /tmp/output cd /tmp/output dump 0Bf 2000000 - /dev/md100s1 | restore rf - && rm restoresymtable This was hand written here in vi, so probably has lots of sharp edges. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Fri Mar 23 16:32:54 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6272F5753E for ; Fri, 23 Mar 2018 16:32:53 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: from smtp-out.ujezd.net (smtp-out.ujezd.net [81.90.241.92]) by mx1.freebsd.org (Postfix) with ESMTP id 681DB7D435 for ; Fri, 23 Mar 2018 16:32:52 +0000 (UTC) (envelope-from knezour@weboutsourcing.cz) Received: by smtp-out.ujezd.net (Postfix, from userid 1001) id 40786z6B8dz9sRd; Fri, 23 Mar 2018 17:26:19 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on smtp-out.ujezd.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=7.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 Received: from [172.22.201.67] (unknown [10.128.99.254]) by smtp-out.ujezd.net (Postfix) with ESMTP id 40786z2Sbtz9sKL for ; Fri, 23 Mar 2018 17:26:19 +0100 (CET) Subject: Re: Easiest way to get a small VM disk image? To: freebsd-hackers@freebsd.org References: From: Ondra Knezour Message-ID: <54b43b2c-4815-2495-33ab-b745f7d02571@weboutsourcing.cz> Date: Fri, 23 Mar 2018 17:26:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000501030900060803080708" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 16:32:54 -0000 This is a cryptographically signed message in MIME format. --------------ms000501030900060803080708 Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Language: cs Content-Transfer-Encoding: quoted-printable Dne 23.03.2018 v 16:42 Kamila Sou=E8kov=E1 napsal(a): > [...] > The VM images available in the official downloads have a virtual size o= f > 20GB. Therefore I need to somehow build my own image (or shrink the > existing ones). Here are the approaches I have thought about: >=20 > [...] > - Create an empty image, boot it in a VM and install from an installati= on > ISO. Problem: not sure how to automate; might not get 1:1 parity with t= he > official VM image This is way I use. Create VM, install what I want, use as template. For=20 automation, search firstboot in rc(8) [1] - generally you may want to=20 delete keys for the sshd daemon to recreate new ones for each VM, maybe=20 set hostname and/or IP addresses if not provided by DHCP etc. > - Somehow shrink the existing image. Problem: How? AFAIK there is no way to shrink a UFS partition. Only create new one,=20 smaller and dump & restore. > - Find out how the official images are built and do that with a smaller= > size. This is where this list comes in :-) See the FreeBSD Release Engineering article [2] and release(7) [3] man=20 page. Search VMFORMATS and/or CLOUDWARE on the later one. There are also other tools which may give you some insight how can be=20 FreeBSD image building customized, search Google for nanobsd, picobsd,=20 chrochet, freebsd wifi build >=20 > Which (of these, or any other) is the easiest way to get a small image?= [1]=20 https://www.freebsd.org/cgi/man.cgi?query=3Drc&apropos=3D0&sektion=3D8&ma= npath=3DFreeBSD+11.1-RELEASE&arch=3Ddefault&format=3Dhtml [2]https://www.freebsd.org/doc/en_US.ISO8859-1/articles/releng/article.ht= ml#release-build [3]=20 https://www.freebsd.org/cgi/man.cgi?query=3Drelease&apropos=3D0&sektion=3D= 0&manpath=3DFreeBSD+11.1-RELEASE&arch=3Ddefault&format=3Dhtml#end --=20 S pozdravem Ondra Knezour --------------ms000501030900060803080708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: Elektronicky podpis S/MIME MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC Dh8wggZfMIIFR6ADAgECAgFxMA0GCSqGSIb3DQEBCwUAMFsxCzAJBgNVBAYTAkNaMSwwKgYD VQQKDCPEjGVza8OhIHBvxaF0YSwgcy5wLiBbScSMIDQ3MTE0OTgzXTEeMBwGA1UEAxMVUG9z dFNpZ251bSBSb290IFFDQSAyMB4XDTEwMDExOTExMzEyMFoXDTIwMDExOTExMzAyMFowXzEL MAkGA1UEBhMCQ1oxLDAqBgNVBAoMI8SMZXNrw6EgcG/FoXRhLCBzLnAuIFtJxIwgNDcxMTQ5 ODNdMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxpZmllZCBDQSAyMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAptFF5UWWYyihAP9nMkD0zv3ctxmK8dG9YQbyOwSmnbFNrJHX ui+zw4x6hgqO8ajo8N+QImz6wFhLSrlZAUCl1aTKX+1Q7DWhnZI9Krq5gslTI5hIo8w6ArPi 7de4HgqLVn6LwVvvN5HJ7p6pqEr62qXdkAmeskqALhfZNrVEqTEr4e7Vt2FYkDeDAv5aQhls v89gjON6375PyyxYrU9Z0FexJ8o5OKQ3Nm3ZU8RMBAMGk5jGoCAt8JFtxv0pTZYgxPc03Egu 7ew2X44z2BX8ZY73jckew4wBXIlJBERpmSwbkoPPM3NBL8uxtiQW2ckCaaHuD2n0KLpwQn6l 8FO0wQIDAQABo4IDKDCCAyQwgfEGA1UdIASB6TCB5jCB4wYEVR0gADCB2jCB1wYIKwYBBQUH AgIwgcoagcdUZW50byBrdmFsaWZpa292YW55IHN5c3RlbW92eSBjZXJ0aWZpa2F0IGJ5bCB2 eWRhbiBwb2RsZSB6YWtvbmEgMjI3LzIwMDBTYi4gYSBuYXZhem55Y2ggcHJlZHBpc3UvVGhp cyBxdWFsaWZpZWQgc3lzdGVtIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRv IExhdyBObyAyMjcvMjAwMENvbGwuIGFuZCByZWxhdGVkIHJlZ3VsYXRpb25zMBIGA1UdEwEB /wQIMAYBAf8CAQAwgbwGCCsGAQUFBwEBBIGvMIGsMDcGCCsGAQUFBzAChitodHRwOi8vd3d3 LnBvc3RzaWdudW0uY3ovY3J0L3Bzcm9vdHFjYTIuY3J0MDgGCCsGAQUFBzAChixodHRwOi8v d3d3Mi5wb3N0c2lnbnVtLmN6L2NydC9wc3Jvb3RxY2EyLmNydDA3BggrBgEFBQcwAoYraHR0 cDovL3Bvc3RzaWdudW0udHRjLmN6L2NydC9wc3Jvb3RxY2EyLmNydDAOBgNVHQ8BAf8EBAMC AQYwgYMGA1UdIwR8MHqAFBUpjMVFaau4s8Pq/ku4Mdjc8Od2oV+kXTBbMQswCQYDVQQGEwJD WjEsMCoGA1UECgwjxIxlc2vDoSBwb8WhdGEsIHMucC4gW0nEjCA0NzExNDk4M10xHjAcBgNV BAMTFVBvc3RTaWdudW0gUm9vdCBRQ0EgMoIBZDCBpQYDVR0fBIGdMIGaMDGgL6AthitodHRw Oi8vd3d3LnBvc3RzaWdudW0uY3ovY3JsL3Bzcm9vdHFjYTIuY3JsMDKgMKAuhixodHRwOi8v d3d3Mi5wb3N0c2lnbnVtLmN6L2NybC9wc3Jvb3RxY2EyLmNybDAxoC+gLYYraHR0cDovL3Bv c3RzaWdudW0udHRjLmN6L2NybC9wc3Jvb3RxY2EyLmNybDAdBgNVHQ4EFgQUiehM34smOT7X JC4SDnrn5ifl1pcwDQYJKoZIhvcNAQELBQADggEBAHXszZUHjwBcJV9V544ujQsgllyDkTId Qq6tud9/q1A6bJPuDOmQk1jcjeKNbYSsF9Qz/od58zFgopZKziNeoZIrlB/EbQHQ7e4Z8c9L hYV+1o9ICdaTW2Ilnhzjf7NIkJwffef2kOa+3yfSP7pxABkhaHg8+maS9SDe43gTRvNkecfa 4rMy+lWcTrAqaXqhX49R88BI8hhDD2AUQA1wzOnXSFckeuc6jRqU+SXKZl1NWywFfB3OFIGw V6XV5UFK9U7Hr7LzN1uuREs69NWdIxvrMf5+zKBTjSaKZ2jfStj/o3611CFsz+xMLGB1YDLa DR6UA3XOL0nHppDvrCgNyf4wgge4MIIGoKADAgECAgMl0IkwDQYJKoZIhvcNAQELBQAwXzEL MAkGA1UEBhMCQ1oxLDAqBgNVBAoMI8SMZXNrw6EgcG/FoXRhLCBzLnAuIFtJxIwgNDcxMTQ5 ODNdMSIwIAYDVQQDExlQb3N0U2lnbnVtIFF1YWxpZmllZCBDQSAyMB4XDTE3MDgxNDA4MzMy MloXDTE4MDkwMzA4MzMyMlowgbAxCzAJBgNVBAYTAkNaMRcwFQYDVQRhEw5OVFJDWi02ODg4 NTQ4MjEpMCcGA1UECgwgT25kxZllaiBLbsSbxb5vdXIgW0nEjCA2ODg4NTQ4Ml0xCjAIBgNV BAsTATExGjAYBgNVBAMMEU9uZMWZZWogS27Em8W+b3VyMRIwEAYDVQQEDAlLbsSbxb5vdXIx EDAOBgNVBCoMB09uZMWZZWoxDzANBgNVBAUTBlAxODIzNjCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBALMTzolQJ4/7Uw+BlI54R2eFXu6phVh7rkWGtr+SFkhb1XGVFmh1pBhO 5b9t5LZOLDrbwClN/P01/ETkIXV8jelvIm4LwhHLyzgPBFmjflHot0m4gf7og9PGEPl4gmdj aqcvQw9sa5+UUm1vOxA5DblvqGOVm26Nmijz0TGS+2ZGfnP2s4UgKZn9+DNDn/6Tky47rfiJ 7tX1g6VrvD1KgpBEDgNdoxtE/xoL9enoyHrphyTSwrNbEmsDcYNHCKe+Awy6deXkoSyxc1Fa 3BbZgZ6EYWExzh435wl3AI+PKftvprOfgTMr43dWK6hUtE9+LQYE2Cx6O0iFHEkQsDsJUqEC AwEAAaOCBCkwggQlMEoGA1UdEQRDMEGBGWtuZXpvdXJAd2Vib3V0c291cmNpbmcuY3qgGQYJ KwYBBAHcGQIBoAwTCjExMjg5MTE4NjGgCQYDVQQNoAITADAJBgNVHRMEAjAAMIIBKwYDVR0g BIIBIjCCAR4wggEPBghngQYBBAERZDCCAQEwgdgGCCsGAQUFBwICMIHLGoHIVGVudG8ga3Zh bGlmaWtvdmFueSBjZXJ0aWZpa2F0IHBybyBlbGVrdHJvbmlja3kgcG9kcGlzIGJ5bCB2eWRh biB2IHNvdWxhZHUgcyBuYXJpemVuaW0gRVUgYy4gOTEwLzIwMTQuVGhpcyBpcyBhIHF1YWxp ZmllZCBjZXJ0aWZpY2F0ZSBmb3IgZWxlY3Ryb25pYyBzaWduYXR1cmUgYWNjb3JkaW5nIHRv IFJlZ3VsYXRpb24gKEVVKSBObyA5MTAvMjAxNC4wJAYIKwYBBQUHAgEWGGh0dHA6Ly93d3cu cG9zdHNpZ251bS5jejAJBgcEAIvsQAEAMIGbBggrBgEFBQcBAwSBjjCBizAIBgYEAI5GAQEw agYGBACORgEFMGAwLhYoaHR0cHM6Ly93d3cucG9zdHNpZ251bS5jei9wZHMvcGRzX2VuLnBk ZhMCZW4wLhYoaHR0cHM6Ly93d3cucG9zdHNpZ251bS5jei9wZHMvcGRzX2NzLnBkZhMCY3Mw EwYGBACORgEGMAkGBwQAjkYBBgEwgfoGCCsGAQUFBwEBBIHtMIHqMDsGCCsGAQUFBzAChi9o dHRwOi8vd3d3LnBvc3RzaWdudW0uY3ovY3J0L3BzcXVhbGlmaWVkY2EyLmNydDA8BggrBgEF BQcwAoYwaHR0cDovL3d3dzIucG9zdHNpZ251bS5jei9jcnQvcHNxdWFsaWZpZWRjYTIuY3J0 MDsGCCsGAQUFBzAChi9odHRwOi8vcG9zdHNpZ251bS50dGMuY3ovY3J0L3BzcXVhbGlmaWVk Y2EyLmNydDAwBggrBgEFBQcwAYYkaHR0cDovL29jc3AucG9zdHNpZ251bS5jei9PQ1NQL1FD QTIvMA4GA1UdDwEB/wQEAwIF4DAfBgNVHSMEGDAWgBSJ6EzfiyY5PtckLhIOeufmJ+XWlzCB sQYDVR0fBIGpMIGmMDWgM6Axhi9odHRwOi8vd3d3LnBvc3RzaWdudW0uY3ovY3JsL3BzcXVh bGlmaWVkY2EyLmNybDA2oDSgMoYwaHR0cDovL3d3dzIucG9zdHNpZ251bS5jei9jcmwvcHNx dWFsaWZpZWRjYTIuY3JsMDWgM6Axhi9odHRwOi8vcG9zdHNpZ251bS50dGMuY3ovY3JsL3Bz cXVhbGlmaWVkY2EyLmNybDAdBgNVHQ4EFgQUqufjUxGsMA+xtVWU4YLcbVlSzwMwDQYJKoZI hvcNAQELBQADggEBABsAmzl0z0QC4GNX/4anD814EgO8fAky/e0CQi32q//hwlR3lilKKaFv 58pQjPZW6+EDi0yvUTFNI1H232l27PVdWMrvAsbuaP53YcT9X3gLuocysXV6gxFdUl+YTbXH 2xLyf2XPZUwSAvSNq3hoMvEKhG2G1LTtGN4kOlKne3k1kLqjharrvvbXRFKAR/NtLSUPiHoT Yl0VyixfJpRxUcxzxwBPai8mHM5elpucI8Z4jUz/8zYaoXyYNOzo081XtwuD8h/uv1fhwyTu 6oCxsGqcxiWhochkwxBMZ4dE1DRioPUciDW/D0WCS2WXMiwZzmYKA92y3N3V/x0/GDRo1c0x ggNcMIIDWAIBATBmMF8xCzAJBgNVBAYTAkNaMSwwKgYDVQQKDCPEjGVza8OhIHBvxaF0YSwg cy5wLiBbScSMIDQ3MTE0OTgzXTEiMCAGA1UEAxMZUG9zdFNpZ251bSBRdWFsaWZpZWQgQ0Eg MgIDJdCJMA0GCWCGSAFlAwQCAQUAoIIBxzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xODAzMjMxNjI2MTlaMC8GCSqGSIb3DQEJBDEiBCAHrIUv/9cTiIeK mhWXT+LUeThfbpjlZNb6OYjsbg455zBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHUGCSsGAQQBgjcQBDFoMGYwXzELMAkGA1UEBhMC Q1oxLDAqBgNVBAoMI8SMZXNrw6EgcG/FoXRhLCBzLnAuIFtJxIwgNDcxMTQ5ODNdMSIwIAYD VQQDExlQb3N0U2lnbnVtIFF1YWxpZmllZCBDQSAyAgMl0IkwdwYLKoZIhvcNAQkQAgsxaKBm MF8xCzAJBgNVBAYTAkNaMSwwKgYDVQQKDCPEjGVza8OhIHBvxaF0YSwgcy5wLiBbScSMIDQ3 MTE0OTgzXTEiMCAGA1UEAxMZUG9zdFNpZ251bSBRdWFsaWZpZWQgQ0EgMgIDJdCJMA0GCSqG SIb3DQEBAQUABIIBALI4BZsh62XZLXr3CtSTOTEeyGirCk0r5LEM60Y+i8/1Mn2EePlnjiVt 14l2j28cCOQZz+OqiqBHz/JCk3Pk8IkBJxGQeI48rQJMUnfeLBb+qbKwb/bdSjt22nLN2HsU rLljj4Kdon/5D+XoRwse/zEgTRCYd6ta9QDI6ZuWvIAvzvge3C7LQrDzCIsCWp5wtOwhcHxc 999ShmkuSR4bkNzWVg+4tLQbDQPMSVYtK/KLm8uGzhIrxbas95HVmNBBdaqL39clIwYeD3Bu u6aMSSlecQB7E23C+AoV9FQhpSDmtyPP1DcRPswFTLc6MZlg/cRfC0PXRm6cVE925oFHJRsA AAAAAAA= --------------ms000501030900060803080708-- From owner-freebsd-hackers@freebsd.org Fri Mar 23 19:43:27 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66C80F68804 for ; Fri, 23 Mar 2018 19:43:27 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10B2D88BE1 for ; Fri, 23 Mar 2018 19:43:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from Ticonderoga.HML3.ScaleEngine.net (senat1-01.HML3.ScaleEngine.net [209.51.186.5]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 6841014415; Fri, 23 Mar 2018 19:43:20 +0000 (UTC) Subject: Re: Easiest way to get a small VM disk image? To: freebsd-hackers@freebsd.org References: Cc: =?UTF-8?B?S2FtaWxhIFNvdcSNa292w6E=?= From: Allan Jude Message-ID: <06bdc144-1cbd-c6e8-3a7c-f7110627a1d4@freebsd.org> Date: Fri, 23 Mar 2018 15:43:19 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 19:43:27 -0000 On 03/23/2018 11:42, Kamila Součková wrote: > Hello, > > I want to build an OpenNebula[1]-compatible VM image of FreeBSD 11.1. One > requirement for my use case is that the image should initially be small > (not as in "take up little physical space", but as in "the size of the > virtual disk as visible in the VM should be small". Specifically, I want > the virtual disk size to be no more than 3GB (which should not be a > problem, as the default installation of FreeBSD takes a lot less than 3G). > > The VM images available in the official downloads have a virtual size of > 20GB. Therefore I need to somehow build my own image (or shrink the > existing ones). Here are the approaches I have thought about: > > - Create and partition an empty disk image, rsync the contents of the > official image into it. Problems: AFAIK requires a FreeBSD host to build > (in order to be able to create a UFS filesystem); requires juggling around > with loopback mounts and such. Probably still the most feasible option, but > I am not sure, which is why I'm asking. > - Create an empty image, boot it in a VM and install from an installation > ISO. Problem: not sure how to automate; might not get 1:1 parity with the > official VM image > - Somehow shrink the existing image. Problem: How? > - Find out how the official images are built and do that with a smaller > size. This is where this list comes in :-) > > Which (of these, or any other) is the easiest way to get a small image? > > Thanks a lot! > > Kamila > > [1] https://opennebula.org/ > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > You should be able to generate a version of the official images easily: do an svn checkout, then: make -j <#cpus> buildworld buildkernel cd release make VMSIZE=2944M SWAPSIZE=128M VMFORMATS=raw DESTDIR=/tmp -DNOSRC -DNOPORTS -DNOPKG -DWITH_VMIMAGES vm-install Will create the image in /tmp/vmimages VMFORMATS can also be qcow2, vmdk, or vhd -- Allan Jude From owner-freebsd-hackers@freebsd.org Fri Mar 23 21:01:42 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89187F6E59A; Fri, 23 Mar 2018 21:01:42 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3AE2A8C67A; Fri, 23 Mar 2018 21:01:42 +0000 (UTC) (envelope-from benno@FreeBSD.org) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A2D7420DFB; Fri, 23 Mar 2018 17:01:41 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 23 Mar 2018 17:01:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=GSoh2J2M2IH1AKrh2UBc1L8P1PIDd 6o2uE3DJRO/dVY=; b=kaMQC3uTBEtrtk0k3v027Qza48d74SIoVlVX26AO8jFKy RQ6fUY5hZTCBkiQ7aIbV6MNX1uU3NnTiYdJQEod/10QPrO7z8Ew2yhV0LVp8jv5Y GFtFoYSbdVDkrkNtNokOhkxjbIE1KFSDdnIsUy8BJvPq/fSkhWgCVIhV5uNX8Ddw p9siOPfgcmh+KnKm4tk/7HBvvHZaP2sdp2UVwQc5d/g/DoDkbvmGDRAWlEf91UYa djQkAfdTpjKJzt9Ty0V8295WnO4/pasGIUeekvg83waAm1VBw29S9LZKEVD9cui/ GL6/AiLpPFyzP5MnkAfhC8tdkr6pPEivfQ/PPtPCw== X-ME-Sender: Received: from [10.57.111.169] (unknown [209.63.143.172]) by mail.messagingengine.com (Postfix) with ESMTPA id 0838B7E183; Fri, 23 Mar 2018 17:01:40 -0400 (EDT) From: Benno Rice Message-Id: <35FF5A67-B8CA-43C8-B39E-6797066CBD7E@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Testing requested: Hybrid ISO/USB boot Date: Fri, 23 Mar 2018 14:01:39 -0700 In-Reply-To: <3373772881814803857@scdbackup.webframe.org> Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org To: Thomas Schmitt References: <3373772881814803857@scdbackup.webframe.org> X-Mailer: Apple Mail (2.3445.5.20) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 21:01:42 -0000 > On Mar 22, 2018, at 1:48 PM, Thomas Schmitt wrote: >=20 > Hi, >=20 > Benno Rice wrote: >> I=E2=80=99ve been working on the ability to create hybrid ISO/HDD = boot images for >> x86, a la what Linux systems do with ISOHYBRID. >=20 > Waving friendly over the fence i feel entitled to give some neighbor's > review. Hello! Thanks for your response. [snip] >> https://people.freebsd.org/~benno/hybrid-bootonly.iso.xz >=20 > This does not look much like it addresses EFI. >=20 > $ xorriso -indev hybrid-bootonly.iso -report_el_torito plain = -report_system_area plain > ... > El Torito catalog : 19 1 > El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz = LBA > El Torito boot img : 1 BIOS y none 0x0000 0x00 4 = 20 > El Torito boot img : 2 BIOS y none 0x0000 0x00 1600 = 24 > ... > MBR partition table: N Status Type Start Blocks > MBR partition : 1 0x80 0xa5 1 16 >=20 > UEFI 2.4, 12.3.2.1, says about El Torito: > "A Platform Id of 0xEF indicates an EFI System Partition." > But entry 2 of this catalog is in a section with Platform Id 0x00 (x86 = BIOS). >=20 > If byte 38977 (decimal) was 0xef rather than 0x00, then it would be = marked > as an El Torito boot image for EFI. I think I=E2=80=99ve addressed this in this revision: https://svnweb.freebsd.org/changeset/base/331463 = And I=E2=80=99ve regenerated the image here: https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz = > Further: This section begins at byte address 38976 by a byte value = 0x90. > According to El Torito specs this means that another section follows. > Correct would be value 0x91, which announces the end of the catalog. > (El Torito 1.0, Figure 4, Offset 0) I=E2=80=99ll look into this too. > On HDD, EFI looks for specially marked partitions in GPT or MBR = partition > table. > In MBR partiton table it looks for a partition of type 0xEF. > (UEFI 2.4, 5.2.2) > In GPT it looks for Type GUID C12A7328-F81F-11D2-BA4B-00A0C93EC93B. > (UEFI 2.4, Table 19) >=20 > So to mark the EFI partition, hybrid-bootonly.iso should have a MBR > partition number 2 with type 0xEF, start at 512-byte block 24*2048/512 = =3D 96, > size 1600 blocks. > (Strangely El Torito addresses by 2048-byte blocks but counts by = 512-byte > blocks. Size limit is 65535 blocks. But counts 0 and 1 mean to EFI > "up to end of medium=E2=80=9D.) I=E2=80=99ll look in to this one too. >> I=E2=80=99ve tested this image under qemu=20 >=20 > OVMF/SDK-II/Tianocore is too tolerant with the EFI specs and with = silently > using BIOS boot equipment. Real iron EFIs insist much more in = compliance. So it appears. Thanks again for looking at this! Thanks, Benno.= From owner-freebsd-hackers@freebsd.org Fri Mar 23 21:16:35 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5348EF6F933; Fri, 23 Mar 2018 21:16:35 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0C188D371; Fri, 23 Mar 2018 21:16:34 +0000 (UTC) (envelope-from scdbackup@gmx.net) Received: from scdbackup.webframe.org ([91.8.164.220]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MUHbK-1f8jBx149i-00R2pY; Fri, 23 Mar 2018 22:16:27 +0100 Date: Fri, 23 Mar 2018 22:14:41 +0100 From: "Thomas Schmitt" To: freebsd-hackers@freebsd.org Subject: Re: Testing requested: Hybrid ISO/USB boot Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Cc: freebsd-current@freebsd.org References: <35FF5A67-B8CA-43C8-B39E-6797066CBD7E@FreeBSD.org> In-Reply-To: <35FF5A67-B8CA-43C8-B39E-6797066CBD7E@FreeBSD.org> Message-Id: <31624772818301324998@scdbackup.webframe.org> X-Provags-ID: V03:K0:FKSV0wJv7Yo7JeIYvEDPbUaOlh0fjx4L9dbywZ75rhrs9PuQbiS UO7HxVCdWmyKJC5JDFT8xngvKzhZIrLUD42Xq+uGA0rnZROsNzZAb6ePqfZP8bLCKADsvar vm9x4kgewl++9E9nxTeP0fOZpyH7UywJHF0o0f5cFxeHiLHsGzqM2A8iVK3UkeDKuREC7EX dhB47EnO6CyAxswiADtBQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:sSR5wYRwZVI=:Q/jIOPJMJCNQRLudrf2T9I mGhvfxwIgxuARuLjR3cbI3THhhCA3FSCeIiDeD414skteEKvjP5MaW8/lGgr3nPQw0ffdwL/l I6EpvFTDThwC9caSVUy8OlrAzOObiUn3wO95Tm5rDJbLbMsrJmHBfPUCkTKNR3wuwTpXkOi7Q O1nH1yNkZR74xfdKQzZfzow6R29jWLN/qYfVCvfTGJzYL3Jns8OGWTHxjXf1hpGVgQ2QS8R9+ qa/ds1Fq2pIH4Xvm2liEwc7Qa0WyNqnYjN1pLbh/mb57pQANikwjHf6ZWTxmo99VPXSHq4Yij +NrIlNYrZTdG4I/QWWYPOL20w+bkuCx/agdh1hDyQIoM2hJ4lFZqiLh7k7PhdClQOR3nset7K 0ENrIbZEDN766aFe9g7HZaUVOhFFTfuwtxfydl/S87jknsWDZkGoT1FV2hONCCA0g5cs723Oi Ho3EQA3HrnMc09b0l3bsiRvYKV8HUJgAY8LmPfnoIIHT9Wb2u29RGXBkj2QIbMMJShmPzJwFc 8H7neUrxyWygnUF3E3/GhhgOJ/JOZ3KkzruXQGTRpoN2cr0+E7sTQ2QIsaJTKtZdKS6xbh5Ib kHKq3So7thO8IxytvcaoUmMa5xDveNHMuhtLLlf+lRsn7C5gDcGuNjRtJgP07l+YblWiPAk1T VJqibNRs2ZHWbl4OzuwI4EQiou22L63qQEx8oE4U7xZxXp7bKEgnSc0v6EI/NoAQbpKlV83Hm TCI/5NHGZGNHbkl8C8rjxsiaSApm6EZuPHKPKYMZVHnu52WgRN0PRN2WHvPkElS4fgwa0BzT6 efn5AypAUfuSqJ3dNIJ9hgqwj5FYJ8MPlK+X7FDTCDSz79e0Hg= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 21:16:35 -0000 Hi, i wrote: > > If byte 38977 (decimal) was 0xef rather than 0x00, then it would be marked > > as an El Torito boot image for EFI. Benno Rice wrote: > I’ve regenerated the image here: > https://people.freebsd.org/~benno/hybrid-bootonly-20180323-00.iso.xz Looks better now: El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA El Torito boot img : 1 BIOS y none 0x0000 0x00 4 20 El Torito boot img : 2 UEFI y none 0x0000 0x00 1600 24 Have a nice day :) Thomas From owner-freebsd-hackers@freebsd.org Fri Mar 23 22:53:50 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21F63F52B65 for ; Fri, 23 Mar 2018 22:53:50 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3B8C69415; Fri, 23 Mar 2018 22:53:49 +0000 (UTC) (envelope-from kamisouckova@gmail.com) Received: by mail-it0-f45.google.com with SMTP id b136-v6so4391569iti.3; Fri, 23 Mar 2018 15:53:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NB9gQCkpoIlKmq2NZWskSQHmmNarxsvIZRIZto88WqU=; b=bou51tcltYOWzNcKlQPB/wYTA/YPs8Ts0y0NLP3xN213DhIdJhJHXsEBhQDra06xaW HBe4Iamj4q7jK7e5VY7Zhsjeh8z7dBgV8P0ws+OBxRaxRzTldl7EFeKUBB0DyM55hyys vVhWnr9GfLP7YRUz4lO+PwkUNGHCUdnXubgJr1Uokr16TTcuUVd4YiS4AowECSx0S2S9 f10t3Y67eOqsyLMPcvF4tJ1CtDcJc1SybpT6BHt7B5W0ixxVmDFwrrvd6jvOPFGXyGnT 2Lg6nBwY2HHaLy9Z3XHLkb9pEEnHRHKYCJQp66zOFJ9//J06xHdk7r8G6lbLmO0XafUH gQ9Q== X-Gm-Message-State: AElRT7G5ZhLxjso+yST15kDLbI4SfrL8ihtFnpMd+/VXpvrfU93CCq5A vYI7PuKR/6R9yUhl+YAiiGnAInbt+k8rkt5pe/KQdw== X-Google-Smtp-Source: AG47ELvMiTdO5++Zw4V7Oa3FYpPagZVnAI/iuFOc5xYhbXezdBW83MLbdzf4IytfYbRAWATHkqu8ysjAFYWCIKOKTqQ= X-Received: by 2002:a24:1ad4:: with SMTP id 203-v6mr15288013iti.18.1521845622897; Fri, 23 Mar 2018 15:53:42 -0700 (PDT) MIME-Version: 1.0 References: <06bdc144-1cbd-c6e8-3a7c-f7110627a1d4@freebsd.org> In-Reply-To: <06bdc144-1cbd-c6e8-3a7c-f7110627a1d4@freebsd.org> From: =?UTF-8?B?S2FtaWxhIFNvdcSNa292w6E=?= Date: Fri, 23 Mar 2018 22:53:32 +0000 Message-ID: Subject: Re: Easiest way to get a small VM disk image? To: Allan Jude , freebsd-rwg@pdx.rh.cn85.dnsmgr.net, knezour@weboutsourcing.cz Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2018 22:53:50 -0000 Big thank you to everyone, your suggestions have been very informative! I will go with Allan's solution, as it is simple and should work for future releases too. If you happen to need an OpenNebula image, let me know :-) Best, Kamila On Fri, Mar 23, 2018 at 8:47 PM Allan Jude wrote: > On 03/23/2018 11:42, Kamila Sou=C4=8Dkov=C3=A1 wrote: > > Hello, > > > > I want to build an OpenNebula[1]-compatible VM image of FreeBSD 11.1. O= ne > > requirement for my use case is that the image should initially be small > > (not as in "take up little physical space", but as in "the size of the > > virtual disk as visible in the VM should be small". Specifically, I wan= t > > the virtual disk size to be no more than 3GB (which should not be a > > problem, as the default installation of FreeBSD takes a lot less than > 3G). > > > > The VM images available in the official downloads have a virtual size o= f > > 20GB. Therefore I need to somehow build my own image (or shrink the > > existing ones). Here are the approaches I have thought about: > > > > - Create and partition an empty disk image, rsync the contents of the > > official image into it. Problems: AFAIK requires a FreeBSD host to buil= d > > (in order to be able to create a UFS filesystem); requires juggling > around > > with loopback mounts and such. Probably still the most feasible option, > but > > I am not sure, which is why I'm asking. > > - Create an empty image, boot it in a VM and install from an installati= on > > ISO. Problem: not sure how to automate; might not get 1:1 parity with t= he > > official VM image > > - Somehow shrink the existing image. Problem: How? > > - Find out how the official images are built and do that with a smaller > > size. This is where this list comes in :-) > > > > Which (of these, or any other) is the easiest way to get a small image? > > > > Thanks a lot! > > > > Kamila > > > > [1] https://opennebula.org/ > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to " > freebsd-hackers-unsubscribe@freebsd.org" > > > > You should be able to generate a version of the official images easily: > > do an svn checkout, then: > > make -j <#cpus> buildworld buildkernel > cd release > make VMSIZE=3D2944M SWAPSIZE=3D128M VMFORMATS=3Draw DESTDIR=3D/tmp -DNOSR= C > -DNOPORTS -DNOPKG -DWITH_VMIMAGES vm-install > > Will create the image in /tmp/vmimages > > VMFORMATS can also be qcow2, vmdk, or vhd > > -- > Allan Jude > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > From owner-freebsd-hackers@freebsd.org Sat Mar 24 13:08:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FBE4F6C2AC for ; Sat, 24 Mar 2018 13:08:34 +0000 (UTC) (envelope-from ztb5129@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B84D56AFC8; Sat, 24 Mar 2018 13:08:33 +0000 (UTC) (envelope-from ztb5129@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id z184so15771139qkc.1; Sat, 24 Mar 2018 06:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=2m4fo1u3Wyjnn1Bi7ZclDxoQF6EOyDPUUzchLnj5xGg=; b=BAsKj6sojQFJ106EIUTJpyta84Pr+VcZsLH3+azyZn2kDxYqjYffLQBm/q8MjyR4Ti CbCZ2NZJK6NfItUZ/Y2oKuvjvI+GsZTP5dakhMUthOWszd6c2BznN97HZiIcpELxAcaY MsYGpbV86ORHyY9+4rwK9swF4VEHCjoH7dH5pqJ36+CNX9PlI3SQ2iikmqRNuNeswzOg GdihmwvTZDwfH1ySAQKwsRK0IVjtDFNrS7a7+ba3mOpJFARfRSAF2DpSaOfcYFHmwHWU /P6MXPWlzrcooiwUh/UhBuNDnjrcyP1E76W/mqFG5s92cijpgicDHG50UUNg1KC+ZJIA /mAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=2m4fo1u3Wyjnn1Bi7ZclDxoQF6EOyDPUUzchLnj5xGg=; b=qNQ9oGvE/3HP4s9+0JU+MgN1biuPx/zc/newPaExyypSu2wmzmcsSgAH4G4+4g4Qhe WLlc18tAC/0gTR2M5dDFrg7BZ7KlKs4d+OkjE9R6kztZGWp5mV0QJGIwTu5cCYRk/KIy 9/lF8yu/M2oX/0H7HGBQpwXV19RM7U+LNQHZA30mRu3ZyfPgJujneA5bIoQhDEpKnnCQ R0/TMiATHUQLu3OVwAjMi/nQpcpBzhzMxByjQWpR26LTVOfvTJpkDkzFpDlmiZq752NT 29XwtALqiupY76j6NXSeT6wB7syiIrbYyKDqVcZ78rOwjzKVntF0krjE9nBQtFwOUb6F 4C/Q== X-Gm-Message-State: AElRT7H3/NFfq+nOlULOmFOSGzJv9/+W52ftPx6llfM2kBBIomaQIz3D 6TfbwostNnUuwsjB71wjnHifjLnQH5G9sLRwJrttLhw= X-Google-Smtp-Source: AG47ELus6g5SsvhYEAUW4X1/5V9LO5tVOXqYo5G5vCJRbf2e/fkv+ZQlUVFB6wTE5VsyMLeIDws77DzO86hFyrDX9Es= X-Received: by 10.55.185.69 with SMTP id j66mr46742663qkf.216.1521896913105; Sat, 24 Mar 2018 06:08:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.19.201 with HTTP; Sat, 24 Mar 2018 06:08:32 -0700 (PDT) From: Tongbo Zhang Date: Sat, 24 Mar 2018 21:08:32 +0800 Message-ID: Subject: [GSoC] Proposal draft on "Dual-stack ping(1) command" To: gavin@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 13:08:34 -0000 Hi all, I am Tongbo Zhang, a graduated student from Jilin University, China. My major is Computer Science and Technology. This year I'd like to participate in GSoC 2018 with FreeBSD on project "Dual-stack ping(1) command" which I think I am capable. I have read some documents and articles to get familiar with network programming. I also browsed the sources of these two commands to find the starting point of coding work. Recently I finished the draft of my proposal, and I really appreciated it if you could review it and give me some advice. Thanks. Best regards, Tongbo Zhang. From owner-freebsd-hackers@freebsd.org Sat Mar 24 14:24:11 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 013B2F4E05D for ; Sat, 24 Mar 2018 14:24:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7200E6EBDE; Sat, 24 Mar 2018 14:24:10 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([96.50.22.10]) by shaw.ca with ESMTPA id zk5QejENGXziTzk5ReEVtx; Sat, 24 Mar 2018 08:24:02 -0600 X-Authority-Analysis: v=2.3 cv=X6B81lbe c=1 sm=1 tr=0 a=jvE2nwUzI0ECrNeyr98KWA==:117 a=jvE2nwUzI0ECrNeyr98KWA==:17 a=v2DPQv5-lfwA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=XYwwmyFA8DYvL4dzhx0A:9 a=wxLij-xC5a6oE-7z:21 a=1Fp-GMWTgbq2zOhI:21 a=CjuIK1q_8ugA:10 a=YNh0pXVPPcyB4c1rYj4A:9 a=BgBBGIletsC0z3rz:21 a=SX2ubfEpBmhHl96G:21 a=-uCzoy1GEY1vxy39:21 a=_W_S_7VecoQA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [192.168.1.101] (S0106002401cb186f.gv.shawcable.net [96.50.22.10]) by spqr.komquats.com (Postfix) with ESMTPSA id D93131204; Sat, 24 Mar 2018 07:23:59 -0700 (PDT) MIME-Version: 1.0 From: Cy Schubert Subject: RE: [GSoC] Proposal draft on "Dual-stack ping(1) command" Date: Sat, 24 Mar 2018 07:24:02 -0700 To: Tongbo Zhang , "gavin@freebsd.org" CC: "freebsd-hackers@freebsd.org" Message-Id: <20180324142359.D93131204@spqr.komquats.com> X-CMAE-Envelope: MS4wfMPSAhosaRatezgGrZVOjYNjmObVrmTvUXGSjh8GG5OEXWH1tVH9y/lUO1lTjkBNBCT+u1f/QG+vb59/KeasMP0KayokKsx2h1v5zMPr7v/JajHcKhtw 59u5Jv5FcQ+rUb8mr4836rPglYNg40fsYhNzHSdV6/Dc+Vnb8b9XfYqIqTx7tZ73I/dalDb2ZvIAuXhVTrwjlikM65UOmGsIYiCVgpfG5nwTqGm5BaHOVmWb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 14:24:11 -0000 This would be easy. Simply merge ping and ping6. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -----Original Message----- From: Tongbo Zhang Sent: 24/03/2018 07:04 To: gavin@freebsd.org Cc: freebsd-hackers@freebsd.org Subject: [GSoC] Proposal draft on "Dual-stack ping(1) command" Hi all, I am Tongbo Zhang, a graduated student from Jilin University, China. My major is Computer Science and Technology. This year I'd like to participate in GSoC 2018 with FreeBSD on project "Dual-stack ping(1) command" which I think I am capable. I have read some documents and articles to get familiar with network programming. I also browsed the sources of these two commands to find the starting point of coding work. Recently I finished the draft of my proposal, and I really appreciated it if you could review it and give me some advice. Thanks. Best regards, Tongbo Zhang. _______________________________________________ freebsd-hackers@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@freebsd.org Sat Mar 24 15:43:16 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 755F1F551A3 for ; Sat, 24 Mar 2018 15:43:16 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D725F7238A for ; Sat, 24 Mar 2018 15:43:15 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-wm0-x232.google.com with SMTP id a20so10796104wmd.1 for ; Sat, 24 Mar 2018 08:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OrfvJPlrjkyuxSZfyn95ESPCyuwWh/1iveyFMQJnzbw=; b=kS0XhOJmu5Ya3howXSthB7ua5DoLQwAZzehe4EKRvOl/C8HC47NKvbQ/ZhMG/ZE4rI uBK4+iTR2001qOPOHxbmQPyuk1DgTa1BEll7Agcb2DpZbQzIdr/Pr49gmZpVFnCjUuBj 53LDL5mUfu+JQDOCN6gwZavlpS9lFNjCdN9KHfdOm6lDuOqc+VjWLQLhuxYzq/SWkekA 7lfU/d2pvinOYZ/joxj7Fvjhbfu8sw4M/brWFQ2W8X1/liYa3VWXhJOIbDN6R/urACBh 8lhsXceBnmN+od+L47p0256/TD27gyT5llymwbPkIoDG0qq9K457v0EI/kfAsIoNOu9t 2f5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OrfvJPlrjkyuxSZfyn95ESPCyuwWh/1iveyFMQJnzbw=; b=JZTM6+9AnEF6EiouvOhxphmFWqUzsy+pHVxhTvzidRmkoOuUb71b+tkcr9z/ilf3Yo zf7vFwmTVw0YrQa9GUzFQFGd4t0NvFeeo2Ldqq6UpIoIcfIQ60tioRMrqc8apEAzYAd/ 1CsV13g5cTbLckq9CX+li6tu5XLFUNHYVfRMz+ncVRdpqapRAIMFpl/G5SCVQ+NZIJPc /99ZFbBVVOmgTAlMjbZhuAcbvQT3IWPnjW9IKcOH+rBi2hLZwiYSZOWN9eYCkt+wVVYz FZKK4x7TM538K23I8t6TXHlRur6Ykbpq3vFd0cW20hey/Xq2f8lpyB/7EmVjSdrR3P8o 8Qzw== X-Gm-Message-State: AElRT7EbbgyRGAhR9Fj4sCGRkYlSkN73hf0dg5Hq8FOJ9qTzgkuEhOTF NA1FUNyDRziiYGUxappFoMPiT/1ztkeOAkKtpKtETYXg X-Google-Smtp-Source: AG47ELtHoqYXTTUseHCAX2AsJ0e9BVSBcEEgubCHAQAgg/ZWAhJ2rvg1JiPgO9buG+eQZYTFxYxlJXoNeyTVMD2a6H8= X-Received: by 10.80.173.75 with SMTP id z11mr34861428edc.306.1521906194185; Sat, 24 Mar 2018 08:43:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.138.1 with HTTP; Sat, 24 Mar 2018 08:43:13 -0700 (PDT) From: Pratyush Yadav Date: Sat, 24 Mar 2018 21:13:13 +0530 Message-ID: Subject: [GSoC] Proposal feedback. To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 15:43:16 -0000 Hi, I would like to work on "Import the Xen grant-table bus_dma(9) handlers from OpenBSD" from the ideas page this GSoC. I have created a draft of my proposal, and would like to hear some feedback on it. The drive link is: https://docs.google.com/document/d/1krro9lmaKNU5XR7UT1gaSXzA5KvFWy8V8X9P7LAzHVM/edit?usp=sharing Thanks, Pratyush Yadav From owner-freebsd-hackers@freebsd.org Sat Mar 24 15:44:34 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B3C1F55330 for ; Sat, 24 Mar 2018 15:44:34 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1304072464 for ; Sat, 24 Mar 2018 15:44:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 16919628-2f7a-11e8-91c6-33ffc249f3e8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 16919628-2f7a-11e8-91c6-33ffc249f3e8; Sat, 24 Mar 2018 15:43:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w2OFhJ8X052363; Sat, 24 Mar 2018 09:43:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1521906199.51564.19.camel@freebsd.org> Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? From: Ian Lepore To: Andriy Gapon , FreeBSD Hackers Cc: Konstantin Belousov Date: Sat, 24 Mar 2018 09:43:19 -0600 In-Reply-To: <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> References: <1521383420.99081.87.camel@freebsd.org> <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 15:44:34 -0000 On Fri, 2018-03-23 at 11:56 +0200, Andriy Gapon wrote: > On 18/03/2018 16:30, Ian Lepore wrote: > > > > Now for the bad news: don't use it. It doesn't work. It's 100% a bug > > in the code that maybe kinda-sorta seemed to work for whoever added it, > > because accidentally the right garbage was on the stack in the local > > nostop var. The generic transfer code doesn't check that the accessor > > failed so it ends up using stack garbage for nostop. The reason > > there's g'teed to be no such ivar is because the code is asking the > > wrong device, and it doesn't even have a handle to the right child > > device to get the info it wants. > > Oh, indeed. > I think that there never was an intention to make "nostop" a property of an i2c > slave, a child of an iicbus device.I think that instead it was supposed to be > a property of the iicbus's parent device, an actual i2c adapter driver. > I guess that the reason that "nostop" became an ivar in iicbus was an incorrect > understanding of how a "bit-banger" device (something implementing iicbb_if), > iicbb device and iicbus device are connected.I think that I was among the > reviewers and I probably had a bit of confusion back then. > > > It seems that the only place where iicbus_get_nostop() is used is > iicbus_transfer_gen().iicbus_transfer_gen is used in several i2c drivers as an > iicbus_transfer method.it's also used in iicbb, thinly wrapped by > iicbb_transfer(). > So, iicbus_get_nostop() actually translates to a call to BUS_READ_IVAR(parent, > device, 1, &v) where I already substituted one for IICBUS_IVAR_NOSTOP. > Here we can see that while the accessor functions lok quite nice they get > expanded to generic calls without much context.So, whether that > BUS_READ_IVAR() call succeeds and what value it gets depends on whether the > parent bus defines an ivar with a value of 1 and what value that ivar might have > for the driver device.Many buses define at least a couple of ivars. > So, a return value of iicbus_get_nostop() could be consistent for a particular > driver while still being arbitrary.But it can be a piece of stack garbage too, > just as you said. > > The only place where iicbus_set_nostop() is used is intel_iicbb_attach(). > In that case the ivar is "set" on a wrong device at all (the bit-banger, not iicbb). > > > This definitely needs to be fixed / reworked. > Perhaps nostop should become a new interface in iicbus_if and iicbb_if... > I think our whole interface for transfers is conceptually broken. I would like to just redefine the behavior of the interface. I think what I want is basically the same thing that nostop ivar was trying to achieve: Ignore the existing start/stop flags in the transfer structures. When you pass an array of transfers, there is one bus START at the beginning, one bus STOP at the end, and an automatic REPEAT_START between any two transfers in the array where the slave address or direction changes. When there are two adjacent transfers in the array with the same address and direction, that's just one long continuous flow of bytes -- effectively, it's scatter/gather IO. As an optimization, we could define an IICBUS_STOP flag that could be added to any transfer in the array to force a full STOP/START sequence after that transfer and before the next. That would amount to basically a minor optimization... it would be identical to just calling transfer twice. So I'm not even sure it's a good idea. We might need to leave the current broken interface in place for out- of-tree code like proprietary drivers, and define a new transfer method that works the new way. When I started looking at all existing callers of iicbus_transfer() I came to the conclusion that almost all of them followed such identical patterns that I wrote theiicdev_readfrom()/writeto() functions. I figured I would run through the system converting everything I could to those new functions, then whatever changes need to be made to the interface would almost all be in just a couple functions. But that project bogged down then other things came along and I forgot all about it. -- Ian From owner-freebsd-hackers@freebsd.org Sat Mar 24 16:47:29 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39D78F5A80F for ; Sat, 24 Mar 2018 16:47:29 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0DDB74A63; Sat, 24 Mar 2018 16:47:28 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f46.google.com with SMTP id t132-v6so22512912lfe.2; Sat, 24 Mar 2018 09:47:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=QBumXmN2iBCbJgQ0WoSpHynPgGsix8UYHIGnDduMW+0=; b=T3vdd/c/hN9GWtDZ1kvuOt9JlQJLBlI7SJKhzLfLE6sTh6xb9T7L5pKf2DNWWgb385 XUvwo7nTWcq2raWeaOEDbl3vY0ADlbLVbDbWBYsMnR1RCefSvDEfeDXkFLE7B0nnWu5n SC2EmvV7eCyafZm58FSc7IKCh3DgDnv5OMIukkjCmBxdwuHNisiHYrbXAPpx7RRqUACW KhXBF8uvTnXEz43HXYoy7HBRhfgZonwac7zcD7SWvpM5pDywSbl8LyyeUa5223rb/8rJ TxhWh2dw0mX1/7oXz3wWCrW/D9RJ+eg09qdLJMmMB/92YKqiCzqX0LRIxOZjf+w1WEs5 ZdyA== X-Gm-Message-State: AElRT7FqdpMg0ph4+7m2B+k89c8s8J08XQ0j7dq95x5sEErEbUia3hCa ycfVcwTW4YTDsRVHUJ+mE0hB7oAb X-Google-Smtp-Source: AG47ELsTE8El50QVs70fNCJ2Z/u/eZXZMBuRIIeS1jeVhhXr0jAoAGpYdMqzprCOqUwvqS4pPADvCA== X-Received: by 2002:a19:a9d3:: with SMTP id s202-v6mr16581858lfe.30.1521910046780; Sat, 24 Mar 2018 09:47:26 -0700 (PDT) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id c29sm2546538ljd.30.2018.03.24.09.47.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Mar 2018 09:47:25 -0700 (PDT) Subject: Re: Custom I2C and RTC chip drivers: where is iccbus_get_nostop() defined? To: Ian Lepore , FreeBSD Hackers Cc: Konstantin Belousov References: <1521383420.99081.87.camel@freebsd.org> <0b0dee4b-e958-e25c-72d9-1ca296495802@FreeBSD.org> <1521906199.51564.19.camel@freebsd.org> From: Andriy Gapon Message-ID: <2b49cfed-1aeb-47c8-4722-2cf2ceb4dc40@FreeBSD.org> Date: Sat, 24 Mar 2018 18:47:24 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1521906199.51564.19.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 16:47:29 -0000 On 24/03/2018 17:43, Ian Lepore wrote: > I think our whole interface for transfers is conceptually broken. I > would like to just redefine the behavior of the interface. I think what > I want is basically the same thing that nostop ivar was trying to > achieve: > > Ignore the existing start/stop flags in the transfer structures. > When you pass an array of transfers, there is one bus START at the > beginning, one bus STOP at the end, and an automatic REPEAT_START > between any two transfers in the array where the slave address or > direction changes. When there are two adjacent transfers in the > array with the same address and direction, that's just one long > continuous flow of bytes -- effectively, it's scatter/gather IO. I completely agree. If you have a transfer / transaction, then why have STOP+START in the middle it. The current default behavior just does not make sense to me. > As an optimization, we could define an IICBUS_STOP flag that could be > added to any transfer in the array to force a full STOP/START sequence > after that transfer and before the next. That would amount to basically > a minor optimization... it would be identical to just calling transfer > twice. So I'm not even sure it's a good idea. Linux has I2C_M_STOP to force a stop. I guess that it's a workaround for some broken slaves that are confused by repeated start. But as you say, just splitting the transfers would work as well. > We might need to leave the current broken interface in place for out- > of-tree code like proprietary drivers, and define a new transfer method > that works the new way. That would make sense to do. > When I started looking at all existing callers of iicbus_transfer() I > came to the conclusion that almost all of them followed such identical > patterns that I wrote the iicdev_readfrom()/writeto() functions. I > figured I would run through the system converting everything I could to > those new functions, then whatever changes need to be made to the > interface would almost all be in just a couple functions. But that > project bogged down then other things came along and I forgot all about > it. Indeed, these are the most used patterns, so makes sense to have common routines for them. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Sat Mar 24 18:45:49 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C12A7F64E2B for ; Sat, 24 Mar 2018 18:45:49 +0000 (UTC) (envelope-from sumitlakradev@gmail.com) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3B29B7988C; Sat, 24 Mar 2018 18:45:49 +0000 (UTC) (envelope-from sumitlakradev@gmail.com) Received: by mail-wr0-x229.google.com with SMTP id z73so15117039wrb.0; Sat, 24 Mar 2018 11:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ExIGOvftp5vC+rJTu5wtP2KnHrcIIu6IW2+AzlicdcU=; b=tP2IFNMiGUnWyqlMZRE0OLQqj9JAxsQfvHeIN9DxzcSyuN7STOvfKkZbxlp7nBYr3w PPN80+p4M4AjngGQsccsQoyaBdLV1PDlb+EvK6HWyDIQQRXWi95eVww3q0pacBspl7cw 7MCmSz1SBDhOGrCMYRw1og6wlQyDwCuFW+RDK2oxHxSNs+SpGYOxMneEKis+5cWbBmSx l9UnXwUgYu4tfkFXLGCrki/o0xpxnA3uxxSSx9l+GGUgpR70Gmjx27uVEvtRK4fifQfr trvXHzufk+r50rV2ZESMqif8r6XXj3AtafweYCw10qxNCYxTgNMELbseRJcI/iltMc0j 0unA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ExIGOvftp5vC+rJTu5wtP2KnHrcIIu6IW2+AzlicdcU=; b=j6NLdQPxG0Om4Hrd7lPxvCRNdVsreLcQloD5/ngqgUL+SpCkHH0+pk/NLcFMwz+4QY 16bgwqNat05W/6E4a4om6aUT2oOS3yO0uSfXYd/vLpB7nYbjtHBKzsDeIfl1w7WkWUUN LzJkDmoG9rNtMrYRp4ODLf6CP2SzLARmybZecZpF6mHG8nKfXoldLsFZ7OCa5ecbntkx OuedtvkudQrFutN50jShZDW2N0QsWDBkdjWu7A1dQ5y0QQPQ+o63BCCdJmot2ToJpzm0 IcsSDzYoQDkRx/hbjKOzwcTw4uQfANhH6nF9gZOeSiBtJX8c4vyz5Yh7wE8vpqbc//hu NLfw== X-Gm-Message-State: AElRT7GFkOzcmTh3IRvhRYM/6uazFat7/JoqeItYi4i5sYLVmIvYzni8 pgI5ev/2RBx/N8On0Y8WjawyiUjiBJ3kRUp2fXa8Nw== X-Google-Smtp-Source: AG47ELvGymay7NGos4PeVAmYB2ylHSs38v27dM9h45NsRf4TjDjGeA+IxsSKvdwtkHXz2vDByUHM1z14z3XOMl6HFMg= X-Received: by 10.223.159.79 with SMTP id f15mr27665648wrg.115.1521917147541; Sat, 24 Mar 2018 11:45:47 -0700 (PDT) MIME-Version: 1.0 References: <20180324142359.D93131204@spqr.komquats.com> In-Reply-To: <20180324142359.D93131204@spqr.komquats.com> From: Sumit Lakra Date: Sat, 24 Mar 2018 18:45:37 +0000 Message-ID: Subject: Re: [GSoC] Proposal draft on "Dual-stack ping(1) command" To: Cy Schubert Cc: Tongbo Zhang , gavin@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2018 18:45:50 -0000 Hello, I was interested in this project earlier. I was thinking of combining this with the traceroute one, but I decided to go for another project later. You will need to use Raw ICMP sockets to do this. Probably the best way. But you will also need to make your ping command a set-user-id program, as only root user can create raw sockets. And if you do this, you must take extra care not to drop any bugs in the code or it can be a havoc. All the best ! On Sat 24 Mar, 2018, 19:55 Cy Schubert, wrote: > This would be easy. Simply merge ping and ping6. > > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -----Original Message----- > From: Tongbo Zhang > Sent: 24/03/2018 07:04 > To: gavin@freebsd.org > Cc: freebsd-hackers@freebsd.org > Subject: [GSoC] Proposal draft on "Dual-stack ping(1) command" > > Hi all, > > I am Tongbo Zhang, a graduated student from Jilin University, China. My > major is Computer Science and Technology. This year I'd like to participate > in GSoC 2018 with FreeBSD on project "Dual-stack ping(1) command" which I > think I am capable. > > I have read some documents and articles to get familiar with network > programming. I also browsed the sources of these two commands to find the > starting point of coding work. Recently I finished the draft of my > proposal, and I really appreciated it if you could review it and give me > some advice. Thanks. > > Best regards, > Tongbo Zhang. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >