Re: Moving Lua source codes
2013/10/21 Marc Balmer m...@msys.ch: Am 20.10.13 22:02, schrieb Artem Falcon: [...] Ok, here i have a clean diff. Sorry for the attach instead of inline. By the way, do you want to move from malloc(9) to kmem(9) as recommended? I may provide a draft version, if you're interested. Thank you for your diff, I will look at it in a few days (I am not at my office the next few days, being abroad for @work stuff). As for malloc(9) switching to kmem(9), I don't want to do that because of the way how Lua allocates memory. An allocator function is called with some number of bytes to be allocated. We have no control over how many bytes it wants us to allocate. If using kmem(9), we would have to keep track of this allocations, since kmem_free() takes as a second argument the number of bytes to free. kmem(9) is not very usable here imo, since we have to pass the number of bytes to free. Now i see. Thanks for clearing it out. btw, you can also CC tech-kern@, no need to keep this discussion private... Doing w/o a diff, i don't have a sane mail environment now to send it inline. There's few more things. First: you forgot to add MODULE_CLASS_LUA_BINDING to a sys/sys/module.h. Second: kernel side Lua will reject to load bytecode produced by luac cause the first built FPless. A simple solution is to build luac and liblua feeded with FPless luaconf.h and put them under different names. Maybe a more elegant solution is possible?
Re: Why do we need lua in-tree again? Yet another call for actual evidence, please. (was Re: Moving Lua source codes)
Date: Sat, 19 Oct 2013 09:47:14 +0200 From: Marc Balmer m...@msys.ch And now to give you a practical example what I personally do with lua(4) right now: In the past I wrote several tty line disciplines to decode various serial formats. Now I have a need for that again. Doing this in C is of course possible, but I want something more dynamic. So I wrote a tty line discipline that uses Lua to do all the decoding. That works like a charm: Load the script, test, change the script and reload. Really practical. I will release this code once I sorted out a few remaining details. And in the course of this work, I also found deficencies in slattach(8). Please show us the code. It doesn't have to be perfect, but it has to be there in order to make a case.
Vnode API cleanup pass 1
This is the first pass to cleanup the vnode API. It basically moves
some functions and defines out of global scope to make it easier to
work on the vnode life cycle supporting functions.
1) with the attached diff:
- The following defines and functions become private to vfs_vnode.c:
VC_MASK, VC_LOCK, DOCLOSE, VI_IANCTREDO and VI_INACTNOW
vclean() and vrelel()
- Function vrecycle() looses its unused lwp argument.
We now have vtryget(), vget() and vref() to get a reference,
vrele() and vrele_async() to drop a reference and
vrevoke(), vgone() and vrecycle() to drop (possible active) nodes.
With these changes v_usecount will not be changed outside of
vfs_vnode.c so this is a first small step to clean up some messy
parts of the vnode life cycle.
* We could also pass down REVOKEALL to vrevoke() and replace vgone(vp)
with vrevoke(vp, 0) but I prefer to later implement vrevoke()
using vgone().
* As I don't see the race in uipc_usrreq.c I'm not really confident it
is ok to unlock the interlock here.
2) while here I propose to remove vtryget(), it is responsible for
ugly hacks and it doesn't look that effective:
It is currently used by the name cache where some entries have
a ~ 100% hit rate while the overall hit rate is between 5% and 15%.
It saves us two out of ~ ten atomic operations per lookup cycle.
If we want to keep it we should change v_usecount to a function
unsigned
vusecount(vnode_t *vp)
{
return v_usecount MASK;
}
Comments or objections anyone?
--
J. Hannken-Illjes - hann...@eis.cs.tu-bs.de - TU Braunschweig (Germany)
vnapi.diff
Description: Binary data
Re: mpt device shuffling
On Sat, 19 Oct 2013, Edgar Fu? wrote: Strictly speaking, this is not a NetBSD kernel issue. However, I hope that someone more familiar with mpt(4) has come accross that MPT feature before: One additional oddity I faced with Thursday's disc failure was that after physically replacing the failed disc with a spare, the SAS controller decided to assign a new pseudo target id to the new disc, skipping the old disc's 3 and using 8 for the replacement (still at PHY 3). Since the kernel assigns sd and, thus, dk numbers in the order of increasing SCSI target ids, this meant my RAIDframe components now became dk2, 6, 3, 4, 5 (not 2, 3, 4, 5, 6 as before). Not a big deal, but somewhat confusing at midnight. I assume that's intentional behaviour to the benefit of some commercial or GPL-licenced OS software. The renumbering was persistent accoss both a hard reset and a soft power cycle (I didn't try a hard power cycle). Is there a way of reverting to the old sequence or disabling that nonsense in the first place? Actually, it's for Windoze. When I was at Sun we had lots of fun with this quirk of the mpt firmware. mpt pretends to be a SCSI HBA because most operating systems are not capable of handling SAS the way it's supposed to be, a fabric where you identify devices not by their location but by the GUID or disklabel. In order to make it easier to write a driver, the mpt firmware does the job that the OS should be doing, keeping a table of device GUIDs and `device ID' mappings in PROM or NVRAM. The `device ID' is what mpt uses to identify the disk to the driver. There are several numbering schemes the firmware implements. On of them assigns all the IDs based on the device's GUID. Another one assigns the `device ID' based on the port number for directly attached devices. That way if you swap out a broken device with a new one, the new one will have the same `device ID' as the one you removed. It still falls back to the GUID for devices on the other side of a SAS switch. There should be a way to alter the `device ID' assigned to a drive with both the mpt BIOS and the command line utility (who's name escapes me at the moment.) There also should be a way to change the behavior for the assignment of `device ID's to directly attached devices by changing some values in the PROM, but this may be only possible with the command line utility. And, of course, LSI kept changing how this worked across different versions of the MPT firmware so I can't give you details about how your particular setup works. Eduardo
Re: Moving Lua source codes
Am 21.10.13 07:57, schrieb Artem Falcon: [...] There's few more things. First: you forgot to add MODULE_CLASS_LUA_BINDING to a sys/sys/module.h. I merely forgot to commit it, thats fixed now. Second: kernel side Lua will reject to load bytecode produced by luac cause the first built FPless. A simple solution is to build luac and liblua feeded with FPless luaconf.h and put them under different names. Maybe a more elegant solution is possible? Yes, this is an issue. Dunno if we need a 'kluac' or so, at the moment I'd say loading code from source form is ok.
Re: Moving Lua source codes
Marc Balmer wrote: Yes, this is an issue. Dunno if we need a 'kluac' or so, at the moment I'd say loading code from source form is ok. Supporting binary chunks is more challenging because binary format can change completely in a new Lua version. Source code is more stable, there are often small changes in the language too (like new keywords) but I'd say they are manageable. Alex
machfb MMIO versus SPARCle OFW
Hi,
I tracked down why my SPARCle (SPARC laptop) appears to lock up on halt.
The cause is:
http://mail-index.NetBSD.org/source-changes/2012/08/15/msg036624.html
where we use the MMIO registers and alter the BUS_CNTL register. This is
a problem because altering the BUS_CNTL register in this way [*] causes the
OFW console to stop working when we halt.
The solution seemed fairly easy - add a detach routine to machfb to
restore the BUS_CNTL register (patch attached). However, this fails
because wsdisplay0 attaches at machfb0, so we also need a detach routine
for wsdisplay. As wsdisplay0 is the console, we have to force the detach,
so it seemed reasonable to add an additional flag for that (wscons patch
also attached). This works, and halt now returns to the OFW prompt.
However, I have a question about the wscons patch - there is no
wsdisplay_noemul_detach(), so is it sensible to call only
wsdisplay_emul_detach() on detach, or is there configuration where
wsdisplay* at machfb could be wsdisplay_noemul?
Thanks,
J
PS. Patches against against current from 2012/08/15.
PPS. Not yet tested on non-console machfb.
[*] cvs rdiff -u -r1.80 -r1.81 src/sys/dev/pci/machfb.c
--
NetBSD: simple; works; documented/Sailing at Newbiggin
http://www.netbsd.org// http://www.newbigginsailingclub.org/
Index: sys/dev/pci/machfb.c
===
RCS file: /cvsroot/src/sys/dev/pci/machfb.c,v
retrieving revision 1.82
diff -u -r1.82 machfb.c
--- sys/dev/pci/machfb.c15 Aug 2012 17:43:59 - 1.82
+++ sys/dev/pci/machfb.c21 Oct 2013 19:36:36 -
@@ -141,6 +141,7 @@
int mclk_post_div;
int mclk_fb_div;
int sc_clock; /* which clock to use */
+ int sc_use_mmio;/* using MMIO register */
struct videomode *sc_my_mode;
int sc_edid_size;
@@ -191,6 +192,7 @@
{ PCI_PRODUCT_ATI_RAGE_MOB_M3_AGP, 23 },
{ PCI_PRODUCT_ATI_RAGE_MOBILITY, 23 },
#endif
+ { PCI_PRODUCT_ATI_RAGE_L_MOB_M1_PCI, 23 },
{ PCI_PRODUCT_ATI_RAGE_LT_PRO_AGP, 23 },
{ PCI_PRODUCT_ATI_RAGE_LT_PRO, 23 },
{ PCI_PRODUCT_ATI_RAGE_LT, 23 },
@@ -235,9 +237,10 @@
static int mach64_match(device_t, cfdata_t, void *);
static voidmach64_attach(device_t, device_t, void *);
+static int mach64_detach(device_t, int);
-CFATTACH_DECL_NEW(machfb, sizeof(struct mach64_softc), mach64_match,
mach64_attach,
-NULL, NULL);
+CFATTACH_DECL3_NEW(machfb, sizeof(struct mach64_softc), mach64_match,
+mach64_attach, mach64_detach, NULL, NULL, NULL, DVF_DETACH_SHUTDOWN);
static voidmach64_init(struct mach64_softc *);
static int mach64_get_memsize(struct mach64_softc *);
@@ -521,7 +524,6 @@
pcireg_t screg;
uint32_t reg;
const pcireg_t enables = PCI_COMMAND_MEM_ENABLE;
- int use_mmio = FALSE;
sc-sc_dev = self;
sc-sc_pc = pa-pa_pc;
@@ -535,6 +537,7 @@
sc-sc_iot = pa-pa_iot;
sc-sc_accessops.ioctl = mach64_ioctl;
sc-sc_accessops.mmap = mach64_mmap;
+ sc-sc_use_mmio = FALSE;
pci_aprint_devinfo(pa, Graphics processor);
#ifdef MACHFB_DEBUG
@@ -578,10 +581,10 @@
* functions
*/
aprint_normal_dev(sc-sc_dev, using MMIO aperture\n);
- use_mmio = TRUE;
+ sc-sc_use_mmio = TRUE;
}
}
- if (!use_mmio) {
+ if (!sc-sc_use_mmio) {
if (bus_space_map(sc-sc_memt, sc-sc_aperbase, sc-sc_apersize,
BUS_SPACE_MAP_LINEAR, sc-sc_memh)) {
panic(%s: failed to map aperture,
@@ -824,7 +827,7 @@
aa.accesscookie = sc-vd;
config_found(self, aa, wsemuldisplaydevprint);
- if (use_mmio) {
+ if (sc-sc_use_mmio) {
/*
* Now that we took over, turn off the aperture registers if we
* don't use them. Can't do this earlier since on some hardware
@@ -840,6 +843,24 @@
}
static int
+mach64_detach(device_t self, int flags)
+{
+ struct mach64_softc *sc = device_private(self);
+ uint32_t reg;
+
+ if (sc-sc_use_mmio) {
+ reg = regr(sc, BUS_CNTL);
+ aprint_debug_dev(sc-sc_dev, BUS_CNTL: %08x\n, reg);
+ reg = ~BUS_APER_REG_DIS;
+ regw(sc, BUS_CNTL, reg);
+
+ bus_space_unmap(sc-sc_regt, sc-sc_regh, sc-sc_regsize);
+ } else
+ bus_space_unmap(sc-sc_memt, sc-sc_memh, sc-sc_apersize);
+ return 0;
+}
+
+static int
machfb_drm_print(void *aux, const char *pnp)
{
if (pnp)
Index: sys/dev/wscons/wsconsio.h
===
RCS file: /cvsroot/src/sys/dev/wscons/wsconsio.h,v
retrieving revision 1.104
diff -u -r1.104 wsconsio.h
---
