Buses, devices and modules

2006-06-23 Thread Artem Ignatiev

Hi all, I have a question regarding probe and attach routines.

I've got 2 modules: for bus (mybus.ko) and for device (mydev.ko) on  
that bus.


mydev.ko has
MODULE_DEPEND(mydev, mybus, 1, 1, 1);

When kldloading mydev.ko, mybus.ko is loading automatically, then it  
founds its device, attaches properly, and mydev.ko after that founds  
its own device, and attaches to the bus, and all works fine.


When I do 'echo mydev_load=YES /boot/loader.conf', loader loads  
both mydev.ko and mybus.ko, and mybus.ko attaches properly, but  
mydev.ko don't attach to anything.


I suppose this happens because mydev happens to probe for devices  
before mybus creates them, and fails to find anything to attach to.


I'm looking for way to trigger the mydev driver to re-probe after the  
mybus driver actually creates the devices, or may be I'm missing  
something simple (like priority of module probing)?

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: help:Makefile template for device drivers with multiple directories

2006-06-08 Thread Artem Ignatiev


On 08.06.2006, at 14:13, [EMAIL PROTECTED]  
[EMAIL PROTECTED] wrote:


Need your helps again! The following is a Makefile template for a  
device

driver in FreeBSD. But when my driver source codes locate in multiple
directories (such as under osd/, engine/, and cam/), how to write the
Makefile? I have tried but still can not get through this, please  
give me a

help!


Are those sources of a single driver, or just subdrivers? FWIW, look  
at bsd.subdir.mk

Or you can try writing
SRCS+= osd/something.c engine/something_else.c cam/whatever_that_does.c
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: RFC: Adding a ``user'' mount option

2006-04-09 Thread Artem Ignatiev


On 08.04.2006, at 5:04, Jeremy Baggs wrote:

I suppose it would be nice to have something that works out of the  
box, but the solution I have been using
is group permissions on the devices and then making the mount point  
in fstab relative instead of absolute. ie:


/dev/cd0 cdrom   cd9660   ro,noauto 0   0

Each user has a cdrom directory under their home directory. You  
still need mount points designated for all
possible devices though.   Does anyone know  how  Darwin / OsX are  
handling their auto-mount  magic?




There is a /Volumes folder, and each time user inserts usb flash or  
cd, the directory is created in that folder, named after a volume label,

and mounts the media into newly created directory.
Looks like the ``diskarbitrationd'' process is responsible for this.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: newbus questions

2006-03-22 Thread Artem Ignatiev


On 16.03.2006, at 15:06, Artem 'ZaZooBred' Ignatiev wrote:


On Thu, 16/03/2006 12:35 +0100, Milan Obuch wrote:




1. How to create the bus itself, and properly describe its  
interfaces?

skeletons of bus-driver and frontend-drivers would be a GREAT help.


Being far from everything knowing hacker, I just can help with  
what I found

when working on something totally unrelated.
First you need to write .m file describing your methods - they are  
class
description, kind of. There are couple of them - maybe PCI analogy  
(pci_if.m
and pcib_if.m) could help a little to understand their role. Then  
you can use
these methods in your device_method_t array describing your  
device. Actually,
these definitions are something like software bus between parent  
and child
device. And maybe you could get some clue looking at bktr driver,  
which could

be somehow related to your are of interest.


Yes, I've got some clearance in how that something_if.m files are
written, but bktr driver is too complex for me to understand how the
things are done right now. I'll look at it again, though, maybe I  
could

understand the logic of how such things are done, when I could clearly
separate generic logic from implementation of particular hardware
driver.


Okay, now I have got the bus device, the child device. My current  
trouble is

that I want bus driver to provide some methods to child drivers.

So I created saa_bus_if.m file, declared some methods there, made  
implementation

in bus driver and added them using
DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl),

and added the saa_bus_if.c to child driver SRCS.

Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it  
works just as
expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent 
(subdev), ...)
inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to  
generic

function (which returns ENXIO) rather than pointer to my implementation.

The questions are:
Am I going the Right Way(tm) when exporting functions to child  
drivers like that?
If yes, what I must do in order to get the real implementation, not  
the default one?

If no, what is The Right Way(tm)?

Thanks in advance.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: newbus questions

2006-03-22 Thread Artem Ignatiev

On 22.03.2006, at 22:23, John-Mark Gurney wrote:

Okay, now I have got the bus device, the child device. My current
trouble is
that I want bus driver to provide some methods to child drivers.

So I created saa_bus_if.m file, declared some methods there, made
implementation
in bus driver and added them using
DEVICE_METHOD(saa_bus_some_method, saa_some_method_impl),

and added the saa_bus_if.c to child driver SRCS.


You should only add the saa_bus_if.h to the child driver.. the if.c
file is for the part that implementes the bus.. be it one driver, or
part of the kernel...  I'm surprised you aren't getting duplicate
symbols...


Now, when I do SAA_BUS_SOME_METHOD(card, ...) inside bus driver, it
works just as
expected. But when I do SAA_BUS_SOME_METHOD(device_get_parent
(subdev), ...)
inside subdriver, it happens that KOBJLOOKUP(...) returns pointer to
generic
function (which returns ENXIO) rather than pointer to my  
implementation.


The questions are:
Am I going the Right Way(tm) when exporting functions to child
drivers like that?
If yes, what I must do in order to get the real implementation, not
the default one?
If no, what is The Right Way(tm)?


Most of the drivers have code in the default, that will reapply the
function to the parent, so you don't have to do the device_get_parent
in your driver..  They also implement their own lower case wrappers
too...


That's just for sure... I want the method I call to work with the bus'
softc, not with the child's one. Right now I am not sure whether I
really want to have different softc's for the bridge driver and for  
tuner.



This very well could be due to the fact that you're including your
interface twice, and that the second time isn't seeing the same cache
entry in the KOBJ cache..

Why are you compiling the _if.c twice?  If this was to get around
undefined symbols at module load time, I found that you need to add a
MODULE_DEPEND to the module the provides the symbol...


Yeah, I found that out myself already... I really was missing
MODULE_VERSION in a bus driver and MODULE_DEPEND in a child driver.

For now, I have all pieces of a puzzle laid out. I'm able to identify
Philips IC (bridge), check it's subdevice, and subdriver is able to ask
it's parent to do some I2C conversation to test presence of tuner.
I know how bus driver can do something with a child device, and vice  
versa.


I think that it's time to try to write an article, as Milan Obuch  
suggested.

I hope it will save someone from bumping into the walls just like I did.

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: XFree86 debugging

2004-02-24 Thread Artem Ignatiev
On Tue, 24.02.2004, at 12:01, Joan Picanyol wrote:
 [resent from questions@, no luck there :(]
 
 Hi,
 
 I've installed XFree86-Server-snap hoping to get DRI for my Radeon 9200.
 In the process, I've found that X gets SIGABRT after (somewhat) long
 inactivity periods. I recompiled with USE_DEBUG=1 hoping to get a
 backtrace, but I can't find the coredump (even though I see 'core
 dumped' in the console).
 
 Where did it go?
try sysctl -w kern.sugid_coredump=1  sysctl -w
kern.corefile=/usr/tmp/%N.core

So it will go to /usr/tmp even if X will do setgid (which it, probably,
does)

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Creating a ``Magic Button''

2004-02-24 Thread Artem Ignatiev
On Tue, 24.02.2004, at 14:40, Dag-Erling Smørgrav wrote:
 Artem Ignatiev [EMAIL PROTECTED] writes:
  I thought that this will be useful feature - when system is almost dead,
  but syscons's still alive (and you have no debugger in kernel) try to
  minimize loss of data trying to sync your disks, and doing halt.
 
 Ctrl-Alt-Del on the console will do what you want.
I'd better do Ctrl-S before kldloading buggy.ko then Ctrl-Alt-Del (;

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]


Creating a ``Magic Button''

2004-02-23 Thread Artem Ignatiev
Hello, hackers

Friend of mine, who's using linux, showed me once this kind of things:
``When I'm too bored to do shutdown, I use Alt-SysRq button.
Sync-Sync-Sync, remount all fs to r/o, halt'' - or something like that.

I thought that this will be useful feature - when system is almost dead,
but syscons's still alive (and you have no debugger in kernel) try to
minimize loss of data trying to sync your disks, and doing halt.

Adding ``SYNC'' button to syscons  kbdcontrol went fine, but then I
wished to make an accented keys, with all these neat things. I've found
that kbdcontrol don't allows me to use dead keys for entering other,
than just plain ascii symbols. So I wished to change kbdcontrol a little
bit more, to allow entering keys like ``pdwn'' from accents. So - the
last thing to do is to change definition of accentmap_t like this:

--- /sys/sys/kbio.h Mon Feb 23 22:24:24 2004
+++ kbio.h  Mon Feb 23 23:07:01 2004
@@ -179,13 +179,13 @@
 #define F(x)   ((x)+F_FN-1)
 #defineS(x)((x)+F_SCR-1)
 #define ACC(x) ((x)+F_ACC)
 
 struct acc_t {
u_char  accchar;
-   u_char  map[NUM_ACCENTCHARS][2];
+   u_short map[NUM_ACCENTCHARS][2];
 };
 
 struct accentmap {
u_short n_accs;
struct acc_tacc[NUM_DEADKEYS];
 };

but immediately after applying this patch, PIO_DEADKEYMAP suddenly
disappeared (kbdcontrol gets ENOTTY Inappopriate ioctl for device when
trying to set accentmap). 
I can't find out, what and where depends on acc_t. What am i missing?

Below is the patch of ``what i've done already'', it still lacks some
bits, like accurate dump of accents definitions.

--- ./sys/dev/kbd/kbd.c.origSun Jan 25 03:48:55 2004
+++ ./sys/dev/kbd/kbd.c Mon Feb 23 16:29:13 2004
@@ -1280,7 +1280,7 @@
/* NON-LOCKING KEYS */
case SPSC: case RBT:  case SUSP: case STBY:
case DBG:  case NEXT: case PREV: case PNC:
-   case HALT: case PDWN:
+   case HALT: case PDWN: case SYNC:
*accents = 0;
break;
case BTAB:
--- ./sys/dev/syscons/syscons.c.origSun Jan 25 04:02:07 2004
+++ ./sys/dev/syscons/syscons.c Mon Feb 23 16:57:39 2004
@@ -50,6 +50,7 @@
 #include sys/reboot.h
 #include sys/signalvar.h
 #include sys/sysctl.h
+#include sys/sysproto.h
 #include sys/tty.h
 #include sys/power.h
 
@@ -3355,6 +3356,10 @@
case PNC:
if (enable_panic_key)
panic(Forced by the panic key);
+   break;
+   case SYNC: 
+   printf(Syncing disks\n);
+   sync(thread0, NULL);
break;
 
case NEXT:
--- ./sys/sys/kbio.h.orig   Sun Jan 25 03:55:12 2004
+++ ./sys/sys/kbio.hMon Feb 23 22:24:24 2004
@@ -174,6 +174,7 @@
 #define HALT   0xa1/* halt machine */
 #define PDWN   0xa2/* halt machine and power down */
 #define PASTE  0xa3/* paste from cut-paste buffer */
+#define SYNC   0xa4/* force sync filesystems */
 
 #define F(x)   ((x)+F_FN-1)
 #defineS(x)((x)+F_SCR-1)
--- ./usr.sbin/kbdcontrol/lex.l.origSun Jan 25 04:15:46 2004
+++ ./usr.sbin/kbdcontrol/lex.l Sun Jan 25 04:16:01 2004
@@ -72,6 +72,7 @@
 halt   { return THALT; }
 pdwn   { return TPDWN; }
 paste  { return TPASTE; }
+sync   { return TSYNC; }
 
 NUL|nul{ number = 0; return TNUM; }
 SOH|soh{ number = 1; return TNUM; }
--- ./usr.sbin/kbdcontrol/lex.h.origSun Jan 25 04:16:23 2004
+++ ./usr.sbin/kbdcontrol/lex.h Sun Jan 25 04:16:48 2004
@@ -64,6 +64,7 @@
 #define THALT  289
 #define TPDWN  290
 #define TPASTE 291
+#define TSYNC  292
 
 extern int number;
 extern char letter;
--- ./usr.sbin/kbdcontrol/kbdcontrol.c.orig Sun Jan 25 04:17:01 2004
+++ ./usr.sbin/kbdcontrol/kbdcontrol.c  Mon Feb 23 22:12:07 2004
@@ -238,6 +238,8 @@
return PDWN | 0x100;
case TPASTE:
return PASTE | 0x100;
+   case TSYNC:
+   return SYNC | 0x100;
case TACC:
if (ACC(number)  L_ACC)
return -1;
@@ -360,6 +362,39 @@
return -1;
}
switch ((token = yylex())) {
+   case TNEXT:
+   c2 = NEXT | SPCLKEY;
+   break;
+   case TPREV:
+   c2 = PREV | SPCLKEY;
+   break;
+   case TRBT:
+   c2 = RBT | SPCLKEY;
+   break;
+   case TDBG:
+   c2 = DBG | SPCLKEY;
+   break;
+   case TSUSP:
+   c2 = SUSP | SPCLKEY;
+