Re: Question regarding the array of size 0.
Lord Isildur wrote:
sine one knows the size of the struct, who need the pointer? just
take the displacement.
char* buf; /* some buffer */
struct foo{
int header;
struct funkystruct blah;
};
(struct foo*)buf; /*your headers are here */
(struct foo*)buf+1; /* and your data is here */
The only problem is that:
struct foo {(struct foo*)buf;
int count; - and - (struct foo*)buf+1;
short flags;
char data[0];
};
will have different alignments. If what you want is for data[] to
begin immediately after flags, buf+1 doesn't work.
Oh, and as to the data[] vs data[0] problem, one can always do the
equivalent of:
#if defined(C99STUBS)
# define ARRAYSTUB(x) x[0]
#elif defined(GCCSTUBS)
# define ARRAYSTUB(x) x[]
#endif
struct foo {
int count;
shortflags;
char ARRAYSTUB(data);
};
-JohnG
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Intel driver doc's Take 2.
Random idea from the peanut gallery... Find someone who is NDA'd and knows both the programming manual and the needs of the device driver. Have that person compose a list of those bits of the manual most necessary for getting a working driver. This would be an explicit list of figures, diagrams, tables and text sections. I would assume that Intel legal would then go through the list and give a yea/nay for each item requested. For the contested items, perhaps a redacted/simplified version could be proposed instead, but hopefully the bulk of the request would accepted. Just my $0.02 -JohnG (neither NDA'd or working on the driver) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Question regarding the funcation socket()...
I am trying to find out where the function socket() is actually defined. sys/kern/uipc_syscalls.c cscope is your friend. Moreover is see __P with all the function prototypes. Can anyone tell me what do they mean. I am right now assuming for my work that they just mean blank. Bad assumption. Depending on the compiler, __P either returns the argument passed to the macro or '()'. This is because pre-ANSI C didn't support function prototypes. pre-ANSI int foo(); ANSI int foo(char *, int *, int, int); Again, cscope is your friend. -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Extremely large (70TB) File system/server planning
What would you guys do in this case? :) I'd call up my friendly regional SGI, Sun, IBM, and Compaq reps and have them put together proposals. I'm a former SGI guy and know that we've had a bunch of installations of this size and larger (much larger). It's not that big a deal any more. I don't know if that's true for the other vendors, having xfs and 128 processor machines tends to warp one's definiton of what is "hard". :-) -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
searching physical memory...
All, I'm doing hardware bringup and am suspecting that our adapter is dma-ing to the wrong physical address. We know we're getting a PCI bus transaction when we expect it, but we don't know where it's going. Until the bus analyzer arrives, what's the easiest way to go through physical memory looking for a known pattern? Is it really as simple as opening /dev/mem and marching through it? Thanks, -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SIGBUS when writing to mmap'd device memory...
All, Never mind, problem found. A logic bug was preventing me from setting PROT_READ which was necessary even though these are write-only registers. Thanks, -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
SIGBUS when writing to mmap'd device memory...
All, I'm trying to mmap() a region of device memory into user space. When the user app tries to write to the page, I'm getting a SIGBUS. My code in foo_mmap() looks essentially like: ... voff = bhandle + client_offset; poff = vtophys(voff); return i386_btop(poff); I know that voff is fine as I can write in the kernel to that address and the right things happen. Any ideas? Anything I can do to help narrow down the cause? Thanks, -JohnG To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to test out cron.c changes? (was: cvs commit: src/etc crontab)
delurk Ok, this has gone on long enough that my normal inhibitions about driving down the signal-to-noise ratio of a technical list have long subsided. Folks, cron is a *LOW LEVEL SERVICE* much in the same vein as UDP. Neither one makes strong guarantees about ordering, duplication, or dropped events. Those are for higher layer services, iff they are needed. *BSD may very well have a need for a temporal equivalent to TCP where stronger guarantees are made, but it is not and should not be cron. That said, I can't help dinking with the design :-) What would happen if the definitions of the hour and minute fields were subtly changed to mean "elapsed wall-clock time since local midnight"? Then, the DST conversion is no longer ambiguous. "Two hours since local midnight" only happens once regardless. On days where the clocks change, most scripts would wind up running an hour ahead or behind their usual time, but hey, so are many of the people :-). There would also have to be an entry in the BUGS section noting that some days have 23 or 25 hours, which is accurate. -JohnG /delurk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
