Re:[UPDATE] New Boot-Loader Menu -- version 1.4
Hi Devin, This loader menu is awesome! But as I opinion, items (1,6,7) and (2,3,4,5) are two different thing. 1.Boot[Enter] 6.Escape to loader prompt 7.Reboot These options are booting action. 2.ACPI Support 3.Boot Safe Mode 4.Boot Single User 5.Boot Verbose These options are booting configures. Separate them will be better, like this - |1.Boot | |2.Prompt | |3.Reboot | || |Configuration: | |1.ACPI Support| |2.Safe Mode| |3.Single User Mode| |4.Verbose Boot Mode| |---| Do you think so? At 2011-05-05 16:20:43，"Devin Teske" wrote: >Hello fellow -hackers, > >I'm so very proud to offer the latest update to my new boot loader menu -- >version 1.4 -- addressing ACPI detection, bringing it in-line with HEAD. > >It took some work and a few days, but I got it! Have a look below for six >different displays (three different scenarios -- i386 w/ ACPI, i386 w/o ACPI, >and non-i386 -- each in both B&W and Color). > >Running on i386-compatible hardware supporting ACPI: >B&W (standard): http://twitpic.com/4tlsin >Color (loader_color=YES): http://twitpic.com/4tlt6l > >Running on i386-compatible hardware lacking ACPI support: >B&W (standard): http://twitpic.com/4tltp0 >Color (loader_color=YES): http://twitpic.com/4tlu5w > >Running on non-i386 hardware: >B&W (standard): http://twitpic.com/4tluio >Color (loader_color=YES): http://twitpic.com/4tluuy > >This version is feature complete with HEAD and backward compatible to >7.0-RELEASE. > >I do hope you like this latest version. You can get your update at: > >http://druidbsd.sourceforge.net/ > or >http://druidbsd.sourceforge.net/download/loader_menu-1.4.tgz >-- >Cheers, >Devin Teske > >-> FUN STUFF <- >-BEGIN GEEK CODE BLOCK- >Version 3.12 >GAT/CS/B/CC/E/IT/MC/M/MU/P/S/TW d+(++) s: a- C+++@$ UB$ P@$ L$ E- >W+++ N? o? K? w@ O M++$ V- PS+>++ PE@ Y+ PGP-> t(+) 5? X(+) R(-) tv+ b+>++ DI+ >D+(++) G++ e> h r+++ z+++ >--END GEEK CODE BLOCK-- >http://www.geekcode.com/ > >-> LEGAL DISCLAIMER <- >This message contains confidential and proprietary information >of the sender, and is intended only for the person(s) to whom it >is addressed. Any use, distribution, copying or disclosure by any >other person is strictly prohibited. If you have received this >message in error, please notify the e-mail sender immediately, >and delete the original message without making a copy. > >-> END TRANSMISSION <- > >_ > >The information contained in this message is proprietary and/or confidential. >If you are not the intended recipient, please: (i) delete the message and all >copies; (ii) do not disclose, distribute or use the message in any manner; and >(iii) notify the sender immediately. In addition, please be aware that any >message addressed to our domain is subject to archiving and review by persons >other than the intended recipient. Thank you. >_ >___ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] draft patch to make usr.bin/kdump WARNS?= 6 clean
On Mon, May 2, 2011 at 9:40 AM, Garrett Cooper wrote:
> On Mon, May 2, 2011 at 9:24 AM, Garrett Cooper wrote:
>> -- Forwarded message --
>> From: Garrett Cooper
>> Date: Mon, May 2, 2011 at 9:24 AM
>> Subject: Re: [PATCH] draft patch to make usr.bin/kdump WARNS?= 6 clean
>> To: Arnaud Lacombe
>>
>>
>> On Mon, May 2, 2011 at 9:21 AM, Arnaud Lacombe wrote:
>>> Hi,
>>>
>>> On Mon, May 2, 2011 at 12:10 PM, Garrett Cooper wrote:
I wanted to do something different this weekend, and I picked
usr.bin/kdump as a likely 'victim' for converting from WARNS?= 0 to
WARNS?= 6. I'm curious as to whether or not this is on the right
track, but here's the reasoning I used:
1. Conditionally include diskmbr.h or diskpc98.h based on whether or
not an architecture was non-pc98 or pc98 to avoid duplicate
definitions, because the beforementioned headers are mutually
exclusive.
2. Move the sockfamilyname declaration to kdump_subr.h as it's used in
the generated ioctl.c file.
3. Fix a signed vs unsigned comparison with a simple cast because the
size_t value will be sufficiently small that it can be converted to a
signed comparison.
4. Fix a cast assignment type source//dest value alignment issue on
ia64 assigning a struct sockaddr value to either struct sockaddr_in or
struct sockaddr_in6 by using calloc and memcpy.
5. Fix structure alignment issues on arm by marking some structures as
__packed.
6. Fix a shadowed declaration for flags by renaming a locally scoped
variable to _flags; add appropriate type to field.
7. Remove unused argument to ktruser_malloc.
8. Add missing declarations for ktruser_malloc and ktruser_rtld.
I've run some basic tests and things seem sane (in particular
ktrace'ing ktrace :)... ktrace'ing 'ssh ::1' and ktrace'ing 'ssh
localhost', but I was wondering if there was anything I was missing or
if someone else who ran arm or ia64 could test this patch out for me.
I've run make universe on amd64, i386, ia64, mips, and pc98, and
things seem sane, but I can't play around with those machines to
determine whether or not they're functional at runtime with the above
changes.
Thanks!
-Garrett
>>> I do not see any patch, either inline or attached.
>>>
>>> - Arnaud
>>>
PS Oh yeah... no commit bit means that I can't commit this either, but
I was curious if my approach was correct before getting to that step
:).
>>
>> Yeah... I'm stupid for not attaching it. Need to get more sleep.
>
> Note to self: should be freeing socket structures after use, and I
> should apply similar logic to the rest of the socket inspection code.
> I'll attach another version after I do some more testing.
Here's an updated patch that was run through make universe a
couple of times.
Thanks!
-Garrett
Index: usr.bin/kdump/kdump.c
===
--- usr.bin/kdump/kdump.c (revision 221219)
+++ usr.bin/kdump/kdump.c (working copy)
@@ -99,8 +99,9 @@
void ktrsockaddr(struct sockaddr *);
void ktrstat(struct stat *);
void ktrstruct(char *, size_t);
+void ktruser_malloc(unsigned char * p);
+void ktruser_rtld(int len, unsigned char * p);
void usage(void);
-void sockfamilyname(int);
const char *ioctlname(u_long);
int timestamp, decimal, fancy = 1, suppressdata, tail, threads, maxdata,
@@ -528,13 +529,13 @@
ip++;
narg--;
} else if (ktr->ktr_code == SYS_open) {
-int flags;
+int open_flags;
int mode;
print_number(ip,narg,c);
-flags = *ip;
+open_flags = *ip;
mode = *++ip;
(void)putchar(',');
-flagsandmodename (flags, mode, decimal);
+flagsandmodename (open_flags, mode, decimal);
ip++;
narg-=2;
} else if (ktr->ktr_code == SYS_wait4) {
@@ -1167,7 +1168,7 @@
size_t mapsize;
int refcnt;
char name[MAXPATHLEN];
-};
+} __packed;
void
ktruser_rtld(int len, unsigned char *p)
@@ -1253,10 +1254,10 @@
void *p;
size_t s;
void *r;
-};
+} __packed;
void
-ktruser_malloc(int len, unsigned char *p)
+ktruser_malloc(unsigned char *p)
{
struct utrace_malloc *ut = (struct utrace_malloc *)p;
@@ -1280,7 +1281,7 @@
}
if (len == sizeof(struct utrace_malloc)) {
- ktruser_malloc(len, p);
+ ktruser_malloc(p);
return;
}
@@ -1315,61 +1316,67 @@
printf(", ");
#define check_sockaddr_len(n) \
- if (sa_##n->s##n##_len < sizeof(struct sockaddr_##n)) { \
+ if (sa_##n.s##n##_len < sizeof(struct sockaddr_##n)) { \
printf("invalid");\
break; \
}
switch(sa->sa_family) {
case AF_INET: {
- struct sockaddr_in *sa_in;
+ struct sockaddr_in sa_in;
- sa_in = (struct sockaddr_in *)sa;
+ memset(&sa_in, 0, sizeof(sa_in));
+ memcpy(&sa_in, sa, sizeof(sa));
check_sockaddr_len(in);
- inet_ntop(AF_INET, &sa_in->sin_addr, addr, sizeof addr);
- printf("%s:%u", addr, ntohs(sa_in->sin_por
Embedded switch instead of stadard PHY
Hi, I would like to implement support for embedded switch on WRT350Nv2 router which is based on 88F5181L SoC (ARM). FreeBSD already have support for embedded gigabit card (if_mge) but in case if this router MAC is connected directly to 8-port ethernet chip (88E6131). If I use MII_PHY_ANY scan founds following PHYs on miibus: mge0: mem 0xf1072000-0xf1073fff irq 18,19,20,21,22 on simplebus0 miibus0: on mge0 e1000phy0: PHY 12 on miibus0 e1000phy0: id1=0x0141, id2=0x0c00 e1000phy1: PHY 13 on miibus0 e1000phy1: id1=0x0141, id2=0x0c00 e1000phy2: PHY 14 on miibus0 e1000phy2: id1=0x0141, id2=0x0c00 e1000phy3: PHY 15 on miibus0 e1000phy3: id1=0x0141, id2=0x0c00 ukphy0: PHY 20 on miibus0 ukphy0: ukphy1: PHY 21 on miibus0 ukphy1: ukphy2: PHY 22 on miibus0 ukphy2: ukphy3: PHY 23 on miibus0 if_mge MAC is connected to port 3 of E6131 and port 3 acts in reverse-GMII mode to simulate PHY side. Reason for output above is that E6131 uses non-standard registers on multiple device addresses and on some of them mii_attach fails, and on another it false detects PHY (20-23 above). I would like to hear form more experienced people how to implement this properly, as it is obvious that it cannot be addressed with existing routines. On linux this is implemented as dsa driver (Distributed Switch Architecture) which supports several similar devices (net/dsa/*). Thanks in advance, Damjan___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
