<jrtc27>if you're editing an existing function, follow the function's style <jrtc27>adding to a file, use the file's style <AlmuHS>but most of my work is in new files <jrtc27>adding to a directory, use the style of the other files in that directory <jrtc27>adding a new directory, whatever the parent directory uses <AlmuHS>yes, but in the same directory are many files with many different formatting and styles <jrtc27>and if in doubt, pick either GNU or mach <jrtc27>I personally think mach is the right one to use in the situation, but GNU isn't necessarily *wrong*, that comes down more to personal preference <AlmuHS>I tried to follow GNU style, with the tips that youpi told me some months ago <jrtc27>(and what I think doesn't matter; youpi's the one to please) <jrtc27>yeah but you didn't, you have tabs where there should be spaces, indents that are too big and vary within the same function, spaces missing before ('s <AlmuHS>8 space tabs, spaces after { ... <jrtc27>really, go through your own patches with a fine-tooth comb <jrtc27>look at every line and ask yourself if that is correct <jrtc27>and make sure you have your editor configured to show tabs distinctly from spaces <jrtc27>(in vim, set listchars=tab:>- is handy) <youpi>AlmuHS: best is like jrtc27 said: follow what is majoritarily done around your code <AlmuHS>yes, but there is not a majority <AlmuHS>even in same files, there are many styles <jrtc27>you're not stupid, use your common sense <youpi>follow what is next to what you change <AlmuHS>but in the files wrotten from scratch? <youpi>I'd say like jrtc27: follow the mach stykle <jrtc27>and when submitting patches, first impressions are important; if your patches are messy and inconsistent then people take it to be one or both of: <jrtc27>1. sloppiness, which raises questions about the quality of the code itself <jrtc27>2. laziness, ie you can't be bothered to check your own patches, so why should someone else bother to invest their time in doing so <jrtc27>I don't know the specifics of mach <jrtc27>(FreeBSD has deviated a fair amount from its mach-derived kernel) <jrtc27>but ultimately just look at the other code <jrtc27>if it's got tabs for indents and braces on the same lines as if/else then it's trying to be mach style <jrtc27>so use those files/functions as a reference <AlmuHS>in i386/i386at/com.c, with Mach copyright, there are this style <AlmuHS>in i386/i386at/autoconf.c this other style <AlmuHS> for (master = bus_master_init; master->driver; master++) <AlmuHS> if (configure_bus_master(master->name, master->address, <AlmuHS> master->phys_address, i, "atbus")) <jrtc27>the second one, assuming it's using tabs, looks like mach except { is in the wrong place <AlmuHS> if (off >= 0xa0000 && off < 0x100000) <AlmuHS>two one-line if, one with braces, the next not <jrtc27>one-line ifs are a matter of preference <jrtc27>often style guides don't enforce one or the other <jrtc27>(e.g. that style(9) says "Braces that are not necessary may be left out.", with "may" not "should"/"must") <AlmuHS>i'm using CodeBlocks, a tiny IDE ***Server sets mode: +nt
<damo22>youpi: what should i be calling fsys_init on ? execprocess? <youpi>the goal is to call into rumpdisk <damo22>it seems like it can be done in there <damo22>since it already inits the proc and auth hurd_ports <damo22>can i just call fsys_init after it inits the hurd_ports? <youpi>well, just pass on procserver and authhandle ? <youpi>since that's what you received <damo22>do i need to bump the ref counter? <damo22> err = mach_port_mod_refs (mach_task_self (), <damo22> procserver, MACH_PORT_RIGHT_SEND, +1); <--- here? <youpi>did you use MACH_MSG_TYPE_COPY_SEND ? <youpi>you shouldn't need to bump the ref by hand <youpi>see the comment for the bump above: that's only because _hurd_init consumes a ref <youpi>is the bootstrap port non-null? (surely it's supposed to, but just to make sure) <youpi>you could try to use mach_port_mod_refs on the bootstrap and proc ports, to make sure which one might be invalid <youpi>you have a port_deallocate(procserver) just above <youpi>I don't see why fsys_init would need proc _hurd_ports, you just pass it procserver <youpi>really, I think you can leave it just where it currently is <youpi>just moving it out of the if so it's always done <damo22>so you mean i pass in procserver and set the _hurd_ports inside my fsys_init <youpi>I don't see how it'd be otherwise <youpi>your rump *can't* have _hurd_ports initialized anyway <youpi>since it's started before everything else <youpi>so you'll have to set it by hand anyway <youpi>doing anything later/earlier won't change that <damo22>but fsys_init is called very late <damo22>cant the hurd_ports be set already by then? <damo22>is hurd_ports some constant in glibc? <youpi>sure, but how could it be magically initialized? <youpi>see what I wrote in bootstrap.html <youpi>It initializes the default proc and auth ports to be given to processes. <youpi>but rump is not a child of diskfs <youpi>so it won't just inherit that <damo22>but i thought the fsys_init call calls into my rump i dont see where inheritance matters if its just set in glibc <youpi>what do you mean by "its just set in glibc" ? <youpi>glibc can't magically know what it's supposed to put in there <youpi>that's the whole point of fsys_init() to tell boostrap process what they are supposed to put there <youpi>see how all of auth, exec, proc, startup, diskfs use _hurd_port_set to set it by hand <damo22>is diskfs_S_fsys_init called before rump's fsys init? <youpi>precisely because they're all bootstrap process that don't just inherit it from ext2fs <youpi>the whole point we are dicussing right now is *making* diskfs_S_fsys_init call fsys_init on rump, to trigger an fsys_init call inside rump <youpi>so of course it'll be called before, since that's what triggers it <damo22>so diskfs_S_fsys_init can init the _hurd_ports and then call rumps fsys_init <youpi>rump won't care what ext2fs has in its _hurd_ports <damo22>diskfs_S_fsys_init already inits the _hurd_ports, why do i need to write more code to do that in machdev? <youpi>rump and diskfs have their own _hurd_ports of course <youpi>they're not the same prtocess <youpi>?????????????????????????????????? <youpi>there is no such thing as a global variablke that would be shared by all processess <youpi>I'm amazed how much you can be brilliant, and at the same time lack some pieces of basic knowledge <damo22>but there are some global vars in glibc <youpi>there's really things wrong going on in computer science courses <youpi>so each process has to have it initialized <youpi>that can explain a few things :) <damo22>taught myself how to program by playing with code <youpi>you really should read at least a couple of books for the basic things <youpi>otherwise you'll miss such kind of important information <damo22>maybe you can help me choose something to read some time <youpi>I can mostly advise what I read myself <youpi>the 3 Tanenbaum books: Operating systems, Networks, Architectures <youpi>the Douglas Comer book TCP/IP networking <youpi>Rubini&Corbet's book: Linux Device Drivers <youpi>is a very interesting read as well <youpi>it's not that much about Linux in particular, but on drivers in general <youpi>(that one is available as PDF iirc) <damo22>i started programming at 10 on MS-DOS: GWBASIC <youpi>that wasn't really GWBASIC, but very similar <youpi>ah, you may also want to read the Minix book from Tanenbamu <damo22>at one time i was using windows, macos and "linux" (all at the same time) and then i discovered GNU and decided to ditch proprietary software <damo22>youpi: how do i get a root_pt (port for root directory) ? do i need to copy code from diskfs_make_peropen ? <youpi>oh right you'll need to get that from ext2fs as well <youpi>you are getting an fsys_startup call, right? <youpi>that gives you a control port on ext2fs <youpi>you can then use fsys_getroot() to get a port on the root <youpi>see diskfs_start_bootstrap doing it for exec <youpi>(you can pass a null port for the dotdot) <damo22>i am creating a new root directory node ? <damo22>and creating a port to access it <youpi>you don't need a new root directory node <youpi>you're just asking ext2fs a port on the root of the / FS <youpi>that you can install as CRDIR and CWDIR <damo22>fsys_getroot (diskfs_exec_ctl, root_pt <--- but i need one of these <AlmuHS>if yes, I will apply the same format for the rest of the files <youpi>damo22: see the definition of fsys_getroot in fsys.defs <youpi>when I talked about dotdot, I was talking about that definition <youpi>so in your fsys_getroot call example it's root_pt <gnu_srs>youpi: If I put printfs in proc/wait.c:S_proc_wait() do I have to rebuild libc, i.e. RPC_proc_wait.c? <youpi>RPC_proc_wait.c is just the client side <youpi>the .c file won't be modified <youpi>S_proc_wait() is the server side <youpi>it's compiled entirely separately <youpi>*and* they both execute in different processes! <youpi>so there's no reason why changing one side would require rebuilding the other side <youpi>that being said, as I already said mach_print should be just working <youpi>if it's not, that must be for a trivial reason <jrtc27>AlmuHS: it's a lot better than what I remember, but still a few places (a few blank lines that shouldn't be there, you still have a few instances of "if(", it's "} else" with no new line, * should always have a space before it and don't put a space before the "(" in function definitions/declarations) ***jma is now known as junlingm
<junlingm>youpi: I am a litle bit confused by the new device_intr_ack and device_intro_notify routines. now every device has the two routines. But isn't the service only available from the irq device? Should all other device return not supported? <youpi>I hadn't realized that it would incur that, not really pretty but well <AlmuHS>i've just send a new patches set to the maillist <junlingm>Youpi: Would it make sense if we implement an interrupt line as a regular character device node, and a program may select on it to wait for an interrupt. When an interrupt occurs, there would be a character available, and read it off would mean to ack it? <youpi>there could be some idea there yes <youpi>making the read do the acknowledge would not be convenient <youpi>I don't think the device_read() RPC allows to separate out checking whether data is available, and reading it <youpi>but a device_write() could be used for that <youpi>at least, now we have something that works reasonably well :) <youpi>but feel free to play with something that would be better and replace it <junlingm>indeed. It is just a tiny little inconvenient to write a transalator for device :) The main problem is conceptual confusion. <youpi>well, in the concept it's fine, it should just probably have gone to another interface, like we have a separate interface for the i386 perms <youpi>and we could move the support from the device master port to an opened device without troubles <junlingm>yes gone to another interface makes more sense.